Network Working Group S. Randriamasy, Ed. Internet-Draft N. Schwan Intended status: Experimental Alcatel-Lucent Bell Labs Expires: May 3, 2012 October 31, 2011 Multi-Cost ALTO draft-randriamasy-alto-multi-cost-04 Abstract IETF is designing a new service called ALTO (Application Layer traffic Optimization) that includes a "Network Map Service", an "Endpoint Cost Service" and an "Endpoint (EP) Ranking Service" and thus incentives for application clients to connect to ISP preferred Endpoints. These services provide a view of the Network Provider (NP) topology to overlay clients. The present draft proposes a light way to extend the information provided by the current ALTO protocol. The purpose is to broaden the possibilities of the Application Clients in two ways. Firstly it proposes to include information on multiple cost types in a single ALTO transaction, providing a better mapping of the Selected Endpoints to needs of the growing diversity of Content Networking Applications and to the network conditions. Secondly it proposes new cost types, that are an abstraction of time-sensitive network information as viewed by the Network Provider. All this also helps producing a more robust choice when multiple Endpoints must be selected. There are 2 parts in this draft: the first part initiates protocol extensions to support requests on multiple Cost Types in one single transaction. These first extensions also integrate the discussions within the ALTO Working Group. The second part proposes use cases motivating further definitions of additional CostTypes and Cost related attributes and capabilities. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Randriamasy & Schwan Expires May 3, 2012 [Page 1] Internet-Draft Multi-Cost ALTO October 2011 Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on May 3, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Randriamasy & Schwan Expires May 3, 2012 [Page 2] Internet-Draft Multi-Cost ALTO October 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Proposed ALTO protocol updates for multi-cost transactions . . 7 4.1. Information Resources Directory . . . . . . . . . . . . . 8 4.1.1. Example Multi-Cost specific resources . . . . . . . . 8 4.2. Multi-Cost Map Service . . . . . . . . . . . . . . . . . . 10 4.2.1. Media Type . . . . . . . . . . . . . . . . . . . . . . 10 4.2.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . 10 4.2.3. Input Parameters . . . . . . . . . . . . . . . . . . . 10 4.2.4. Capabilities . . . . . . . . . . . . . . . . . . . . . 10 4.2.5. Response . . . . . . . . . . . . . . . . . . . . . . . 11 4.2.6. Example . . . . . . . . . . . . . . . . . . . . . . . 13 4.3. Filtered Multi-Cost Map . . . . . . . . . . . . . . . . . 13 4.3.1. Media Type . . . . . . . . . . . . . . . . . . . . . . 14 4.3.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . 14 4.3.3. Input Parameters . . . . . . . . . . . . . . . . . . . 14 4.3.4. Capabilities . . . . . . . . . . . . . . . . . . . . . 16 4.3.5. Response . . . . . . . . . . . . . . . . . . . . . . . 16 4.3.6. Example . . . . . . . . . . . . . . . . . . . . . . . 16 4.4. Endpoint Multi-Cost Service . . . . . . . . . . . . . . . 17 4.4.1. Endpoint Multi-Cost . . . . . . . . . . . . . . . . . 18 4.4.2. Media Type . . . . . . . . . . . . . . . . . . . . . . 18 4.4.3. HTTP Method . . . . . . . . . . . . . . . . . . . . . 18 4.4.4. Input Parameters . . . . . . . . . . . . . . . . . . . 18 4.4.5. Capabilities . . . . . . . . . . . . . . . . . . . . . 19 4.4.6. Response TBC . . . . . . . . . . . . . . . . . . . . . 19 4.4.7. Example . . . . . . . . . . . . . . . . . . . . . . . 20 4.5. ALTO Status Codes for Multi-Cost ALTO . . . . . . . . . . 21 5. Use cases for further Cost Types and Endpoint Properties . . . 22 5.1. Delay Sensitive Overlay Applications . . . . . . . . . . . 22 5.2. CDN Surrogate Selection . . . . . . . . . . . . . . . . . 23 6. Proposed additional Properties and Costs . . . . . . . . . . . 24 6.1. The Path Occupation Cost . . . . . . . . . . . . . . . . . 24 6.2. For further extensions: dynamic Costs . . . . . . . . . . 24 6.2.1. Dynamic Cost Attributes . . . . . . . . . . . . . . . 25 6.2.1.1. The dynamic Cost Mode . . . . . . . . . . . . . . 25 6.2.2. Proposed dynamic Cost Scope capability . . . . . . . 25 6.2.2.1. Example of time scope for a dynamic cost . . . . . 26 6.2.3. Example of dynamic information resources in the IRD . 26 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 7.1. Information for IANA on proposed Cost Types . . . . . . . 28 7.2. Information for IANA on proposed Endpoint Propeeries . . . 28 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 9.1. Normative References . . . . . . . . . . . . . . . . . . . 28 Randriamasy & Schwan Expires May 3, 2012 [Page 3] Internet-Draft Multi-Cost ALTO October 2011 9.2. Informative References . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 Randriamasy & Schwan Expires May 3, 2012 [Page 4] Internet-Draft Multi-Cost ALTO October 2011 1. Introduction IETF is designing a new service called ALTO that provides guidance to P2P applications, which have to select one or several hosts from a set of candidates that are able to provide a desired resource. This guidance shall be based on parameters that affect performance and efficiency of the data transmission between the hosts, e.g., the topological distance. The ultimate goal is to improve Quality of Experience (QoE) in the application while reducing resource consumption in the underlying network infrastructure. The ALTO protocol conveys the Internet View from the perspective of a Provider Network region that spans from a region to one or more Autonomous System (AS). Together with this Network Map, it provides the Provider determined Cost Map between locations of the Network Map. Last, it provides the Ranking of Endpoints w.r.t. their routing cost. The term Network Provider in this document includes both ISPs, who provide means to transport the data and Content Delivery Network (CDN) operators who care for the dissemination, persistent storage and possibly identification of the best/closest content copy. The last ALTO protocol draft see [ID-alto-protocol], gives the possibility to query multiple Endpoint properties at once. On the other hand, the Endpoint Cost service in its input specification allows only one Cost Type and Cost mode per request. The ALTO requirements draft, see [ID-ALTO-Requirements7] states in REQ. ARv05-14: "The ALTO client protocol MUST support the usage of several different rating criteria types". In the current protocol draft, there is no specified way to get values for several Cost Types simultaneously. Currently, the costs are provided in a scalar form, one by one. So that an ALTO Client wanting information for several Cost Types must request and receive a response as many times as desired Cost Types. Getting all costs in one single query/response transaction saves time and ALTO traffic load, thus ressources, thus energy. Besides, vector costs provide a robust and natural input to multi-variate path computation as well as robust multi-variate selection multiple Endpoints. Other savings in resources can be obtained by gathering multiple Cost Types in the Cost map and Filtered Cost Map services. Indeed, one Cost Map reporting on N Cost Types is less bulky than N Cost Maps containing one Cost Type each. This is valuable for both the storage of these maps and their transfer. Last, as it is most likely that nowadays applications need information on several cost types, having them gathered in one map will save time. The ALTO Problem Statement, see [RFC5693] and the ALTO requirements draft, see [RFC5693] stress that: "information that can change very Randriamasy & Schwan Expires May 3, 2012 [Page 5] Internet-Draft Multi-Cost ALTO October 2011 rapidly, such as transport-layer congestion, is out of scope for an ALTO service. Such information is better suited to be transferred through an in-band technique at the transport layer instead", as "ALTO is not an admission control system "and does not necessarily know about the instant load of endpoints and links. However, non- real time abstraction of performance oriented information is useful for a reliable choice of candidate endpoints. In addition, given the QoE requirements of nowadays and future Internet applications, more and more NPs compute and store such information to optimize their traffic. Besides specific ALTO servers can be specified for small networks including mobile core networks, which have a smaller scale and can afford and take advantage of using small time-scale network information. Adding QoE-enabling metrics to the Network Provider established routing cost could meet the interests of both the end users and the Providers. 2. Scope This draft generalizes the case of a P2P client to include the case of a CDN client, a GRID application client and any Client having the choice in several connection points for data or resource exchange. To do so, it uses the term "Application Client" (AC). This draft focuses on the use case where the ALTO client is embedded in the Application Client or in some Application Endpoint tracker in the network, such as a P2P tracker, a CDN location tracker or a cloud computing orchestration system implemented in a logically centralized management system. It is assumed that Applications likely to use the ALTO service have a choice in connection endpoints as it is the case for most of them. The ALTO service is managed by the Network Provider and reflects its preferences for the choice of endpoints. The NP defines in particular the network map, the routing cost among Network Locations, and which ALTO services are available at a given ALTO server. 3. Terminology Endpoint (EP): can be a Peer, a CDN storage location, a Party in a resource sharing swarm such as a computation Grid or an online multi- party game. Endpoint Discovery (EP Discovery) : this term covers the different types of processes used to discover different types of endpoints. Network Service Provider (NSP): includes both ISPs, who provide means Randriamasy & Schwan Expires May 3, 2012 [Page 6] Internet-Draft Multi-Cost ALTO October 2011 to transport the data and Content Delivery Network (CDN) who care for the dissemination, persistent storage and possibly identification of the best/closest content copy. ALTO transaction: a request/response exchange between an ALTO Client and an ALTO Server. Application Client (AC): this term generalizes the case of a P2P client to include the case of a CDN client and of any Client having the choice in several connection points for data or resource exchange. 4. Proposed ALTO protocol updates for multi-cost transactions This section proposes updates of the ALTO protocol to support Multi Cost ALTO Services or provide additional ALTO information. It integrates discussions on the ALTO mailing list. If an ALTO client desires several Cost Types, instead of placing as many requests as costs, it may request and receive all the desired cost types in one single transaction. The ALTO server then, provided it supports the requested Cost Types, and provided it supports multi-cost ALTO transactions, sends one single response where for each {source, destination} pair, the cost values are arranged in a vector, where each component corresponds to a specified Cost Type. The correspondence between the components and the cost types MUST be indicated either in the ALTO response or available via the resource directory. The following ALTO services get corresponding services with Multi- Cost extensions: o Information Resources Directory: extended with multi-cost related URIs and associated capabilities. o Cost Map Service: extended with the Multi-Cost Map Service, o Cost Map Filtering Service: extended with the Multi-Cost Map Filtering Service, o Endpoint Cost Lookup Service: extended with the Endpoint Multi- Cost Lookup Service. Randriamasy & Schwan Expires May 3, 2012 [Page 7] Internet-Draft Multi-Cost ALTO October 2011 4.1. Information Resources Directory When the ALTO server supports the provision of information on multiple costs in a single transactions, the Information Resources will list the corresponding resources. The media type and encoding specificarions remain the same as in the current ALTO protocol. 4.1.1. Example Multi-Cost specific resources The following is an example Information Resource Directory returned by an ALTO Server and containing Multi-Cost specific services: the Multi-Cost Map Service, Filtered Multi-Cost Map and the Endpoint Multi-Cost Service. It is assumed that the IRD contains usual ALTO Services as described in the example IRD of the current ALTO protocol. In this example, the ALTO Server provides additional Multi-Cost Services in a specific folder of "alto.example.com" called "multi". This folder contains the Multi-Cost Maps, Filtered Multi- Cost Maps as well as the Endpoint Multi-Cost Service. Randriamasy & Schwan Expires May 3, 2012 [Page 8] Internet-Draft Multi-Cost ALTO October 2011 GET /directory HTTP/1.1 Host: alto.example.com Accept: application/alto-directory+json,application/alto-error+json HTTP/1.1 200 OK Content-Length: [TODO] Content-Type: application/alto-directory+json { "resources" : [ { ..... Usual ALTO "single-cost" Services as described in ALTO Protocol ..... }, { "uri" : "http://alto.example.com/multi/maps", "media-types" : ["application/alto-multicostmap+json"], "accepts" : ["application/alto-multicostmapfilter+json"], "capabilities" : { "cost-constraints" : true, "cost-types" : [ "routingcost", "hopcount" ], "cost-modes" : [ "numerical", "numerical" ] } }, { "uri" : "http://alto.example.com/multi/endpointmulticost/lookup", "media-types" : [ "application/alto-endpointmulticost+json" ], "accepts" : [ "application/alto-endpointmulticostparams+json" ], "capabilities" : { "cost-constraints" : true, "cost-types" : [ "routingcost", "hopcount" ], "cost-modes" : [ "numerical", "numerical" ] } }, { "uri" : "http://custom.alto.example.com/multi/endpointmulticost/lookup", "media-types" : [ "application/alto-endpointmulticost+json" ], "accepts" : [ "application/alto-endpointmulticostparams+json" ], } ] } Randriamasy & Schwan Expires May 3, 2012 [Page 9] Internet-Draft Multi-Cost ALTO October 2011 4.2. Multi-Cost Map Service This section introduces a new media-type for the Multi-Cost map. For each source/destination pair of PIDs, it provides the value of the different Cost Type supported for the Multi-cost map, in the same order as in the list of cost-types specified in the capabilities. A Multi-Cost Map MAY be provided by an ALTO Server. This resource MUST be provided for at least the 'routingcost' Cost Type with the 'numerical' Cost Mode. It is assumed that an ALTO Server supporting multi-cost maps supports the 'numerical' Cost Mode for all Cost Types encoded in the 'JSONnumber' type. Note that the capabilities specify implicitly the order in which the different Cost Type values will be listed in the Cost Map. The Cost Type values in the responses are encoded in with a JSONArray of cost values for the different required cost types. Note also that contrary to the Cost Map service, the returned Multi Cost Map is not required to include the required Path Costs for each pair of Source and Destination PID known to the ALTO Server. The reason is that for a given source/destination pair, the ALTO Server may not have the information on certain Cost Types. As a consequence, contrary to the Cost Map service, the Multi-Cost Map service introduces a particular value that unambiguously indicates that the information is not available. This way, the order in which the cost values are provided for a source/destination pair is unambiguous. 4.2.1. Media Type The media type is "application/alto-multicostmap+json". 4.2.2. HTTP Method This resource is requested using the HTTP GET method. 4.2.3. Input Parameters None. 4.2.4. Capabilities This resource may be defined for multiple Cost Types and Cost Modes. The capabilities of an ALTO Server URI providing this resource are defined by a JSON Object of type MultiCostMapCapability: Randriamasy & Schwan Expires May 3, 2012 [Page 10] Internet-Draft Multi-Cost ALTO October 2011 object { CostType cost-types<1..*>; CostMode cost-modes<0..*>; } MultiCostMapCapability; with members cost-types The Cost Types ( Section 5.1.1) supported by the corresponding URI. This member MUST at least include the type 'routingcost'. The order in which the Cost Type values for a source/destination pair will be listed in the Multi-Cost Map provided to an ALTO Client MUST be the order in which these Cost Types are listed in this member. cost-modes The Cost Mode ( Section 5.1.2) supported for each of the supported Cost Types listed in the "cost-types". For Cost types encoded with the 'JSONnumber' type, the Cost Mode MUST be numerical. It will be interpreted as such if this member is not present. An ALTO Server MUST support all of the Cost Types listed here for each of the listed Cost Modes. Note that an ALTO Server may provide multiple Cost Map Information Resources, each with different capabilities. An ALTO Server supporting the Multi-Cost Map service, MUST support the Cost mode 'numerical' for all supported Cost Types encoded with the 'JSONnumber' type. It also MUST list the Cost Type values associated to a source/destination pair in the same order as in the "cost-types" member of the capabilities specified the Multi-Cost Map resource. 4.2.5. Response The returned InfoResourceEntity object has "data" member of type InfoResourceMultiCostMap: Randriamasy & Schwan Expires May 3, 2012 [Page 11] Internet-Draft Multi-Cost ALTO October 2011 object DstMultiCosts { JSONArray [PIDName]; ... }; object { DstMultiCosts [PIDName]<0..*>; ... } MultiCostMapData; object { CostType cost-type<1..*>; CostMode cost-mode<1..*>; JSONString map-vtag; MultiCostMapData map; } InfoResourceMultiCostMap; with members: cost-mode Cost Mode (Section 5.1.2) used in the Cost Map where each member of the cost-mode list is the Cost Mode provided for the Cost Type at the same place in the list. cost-type Cost Type (Section 5.1.1) used in the Multi Cost Map. map-vtag The Version Tag (Section 5.3) of the Network Map used to generate the Cost Map. map The Multi Cost Map data itself. MultiCostMapData is a JSON object with each member representing a single Source PID; the name for a member is the PIDName string identifying the corresponding Source PID. For each Source PID, a DstMultiCosts object denotes the associated multiple costs to a set of destination PIDs (Section 5.2); the name for each member in the object is the PIDName string identifying the corresponding Destination PID. DstMultiCosts are listed in the same order as in the 'cost-type' array. The returned Cost Map MUST include the required Path Costs for each pair of Source and Destination PID for which this information is available. The members cost-mode and cost-type MUST be arrays with the same number of elements. Note also that the Multi-Cost Map service needs a particular value that unambiguously indicates that the information is not available. Randriamasy & Schwan Expires May 3, 2012 [Page 12] Internet-Draft Multi-Cost ALTO October 2011 As an example this value is referred here to as NAv for "Not available". Note that the type of NAv still needs to be specified: preferably a numerical value for numerical costs that unambiguously means: "not available" and can distiguished from "infinite" or "invalid something" or any "pathological" value. 4.2.6. Example This example illustrates a 'static' multi-cost' ALTO trasaction, where the utilized cost-types all have 'static' values. We assume here that the Cost Types available at the ALTO Server are "routingcost" and "hopcount" and the 'numerical' mode is available for both of them. The "routingcost" may be based on monetary considerations where as the "hopcount" is used to account on the path delay. GET /multicostmap/num HTTP/1.1 Host: alto.example.com Accept: application/alto-multicostmap+json,application/alto-error+json HTTP/1.1 200 OK Content-Length: [TODO] Content-Type: application/alto-multicostmap+json { "meta" : {}, "data" : { "cost-mode" : ["numerical", "numerical"] "cost-type" : ["routingcost", "hopcount"] "map-vtag" : "1266506139", "map" : { "PID1": { "PID1": [1,6], "PID2": [5,23], "PID3": [10,5] }, "PID2": { "PID1": [5,5], "PID2": [1,11], "PID3": [15,9] }, "PID3": { "PID1": [20,12], "PID2": [15,1], "PID3": [1,18] } } } } 4.3. Filtered Multi-Cost Map A Multi-Cost Map may reach a huge volume and also, an Application Client assisted by the ALTO Client does not necessarily need information on all the Cost Types for all the source/destination pairs of PIDs. Therefore, applications may more likely use Cost Map information filtered w.r.t. the Cost types as well as the source/destination Randriamasy & Schwan Expires May 3, 2012 [Page 13] Internet-Draft Multi-Cost ALTO October 2011 pairs of PIDs. This section specifies filtered Multi-Cost Maps. A Filtered Cost Map is a Cost Map Information Resource (Section 7.7.2.2) for which an ALTO Client may supply additional parameters limiting the scope of the resulting Cost Map. A Filtered Cost Map MAY be provided by an ALTO Server. 4.3.1. Media Type The media type is "application/alto-multicostmap+json", see Section 4.2.1 of this draft. 4.3.2. HTTP Method This resource is requested using the HTTP POST method 4.3.3. Input Parameters Input parameters are supplied in the entity body of the POST request. This document specifies the input parameters with a data format indicated by the media type "application/ alto-multicostmapfilter+json", which is a JSON Object of type ReqFilteredCostMap, where: Randriamasy & Schwan Expires May 3, 2012 [Page 14] Internet-Draft Multi-Cost ALTO October 2011 object { PIDName srcs<0..*>; PIDName dsts<0..*>; } PIDFilter; object { CostType cost-type<0..*>; CostMode cost-mode<0..*>; JSONString constraints<0..*>; [OPTIONAL] PIDFilter pids; [OPTIONAL] } ReqFilteredMultiCostMap; with members: cost-type The Cost Type ( Section 5.1.1) for the returned costs. Each listed cost-type MUST be one of the supported Cost Types indicated in this resource's capabilities ( Section 7.7.3.2.4). cost-mode The Cost Mode ( Section 5.1.2) for each of the returned cost-types. For Cost types encoded with the 'JSONnumber' type, the Cost Mode MUST be numerical. It will be interpreted as such if this member is not present. constraints Defines a list of additional constraints on which elements of the Cost Map are returned. This parameter MUST NOT be specified if this resource's capabilities ( Section 7.7.3.2.4) indicate that constraint support is not available. A constraint contains two entities separated by whitespace: (1) an operator either 'gt' for greater than or 'lt' for less than (2) a target numerical cost. The numerical cost is a number that MUST be defined in the same units as the Cost Type indicated by the cost- type parameter. ALTO Servers SHOULD use at least IEEE 754 double- precision floating point [IEEE.754.2008] to store the numerical cost, and SHOULD perform internal computations using double- precision floating-point arithmetic. If multiple 'constraint' parameters are specified, they are interpreted as being related to each other with a logical AND. pids A list of Source PIDs and a list of Destination PIDs for which Path Costs are to be returned. If a list is empty, the ALTO Server MUST interpret it as the full set of currently-defined PIDs. The ALTO Server MUST interpret entries appearing in a list multiple times as if they appeared only once. If the "pids" member is not present, both lists MUST be interpreted by the ALTO Server as containing the full set of currently-defined PIDs. Randriamasy & Schwan Expires May 3, 2012 [Page 15] Internet-Draft Multi-Cost ALTO October 2011 4.3.4. Capabilities The URI providing this resource supports all capabilities documented in Section 7.7.2.2.4 (with identical semantics), plus additional capabilities. In particular, the capabilities are defined by a JSON object of type FilteredMultiCostMapCapability: object { CostMode cost-modes<0..*>; CostType cost-types<0..*>; JSONBool cost-constraints; } FilteredMultiCostMapCapability; with members: cost-modes See Section 4.2.5 of this MC draft cost-types See Section 4.2.5 of this MC draft cost-constraints If true, then the ALTO Server allows cost constraints to be included in requests to the corresponding URI. If not present, this member MUST be interpreted as if it specified false. 4.3.5. Response See Section of this draft for the format. The returned Cost Map MUST NOT contain any source/destination pair that was not indicated (implicitly or explicitly) in the input parameters. If the input parameters contain a PID name that is not currently defined by the ALTO Server, the ALTO Server MUST behave as if the PID did not appear in the input parameters. If any constraints are specified, Source/ Destination pairs that do for which the Path Costs do not meet the constraints MUST NOT be included in the returned Cost Map. If no constraints were specified, then all Path Costs are assumed to meet the constraints. 4.3.6. Example Randriamasy & Schwan Expires May 3, 2012 [Page 16] Internet-Draft Multi-Cost ALTO October 2011 POST multi/multicostmap/filtered HTTP/1.1 Host: alto.example.com Content-Type: application/alto-multicostmapfilter+json Accept: application/alto-multicostmap+json,application/alto-error+json { "cost-mode" : "numerical", "numerical"], "cost-type" : "routingcost", "hopcount"], "pids" : { "srcs" : [ "PID1" ], "dsts" : [ "PID1", "PID2", "PID3" ] } } HTTP/1.1 200 OK Content-Length: [TODO] Content-Type: application/alto-costmap+json { "meta" : {}, "data" : { "cost-mode" : ["numerical", "numerical"], "cost-type" : ["routingcost", "hopcount"], "map-vtag" : "1266506139", "map" : { "PID1": { "PID1": [1,6], "PID2": [5,23], "PID3": [10,5] } } } } 4.4. Endpoint Multi-Cost Service The Endpoint Multi-Cost Service provides information about several costs between individual Endpoints. This service does not allow lists of Endpoint prefixes (and addresses, as a special case) to be ranked (ordered) by an ALTO Server, as firstly the costs encoded with the JSONnumber 'type' are provided in the numerical Mode and secondly the choice among various existing methods to rank Endpoints upon multiple costs (criteria) is out of scope of this protocol and in the responsability of the Application Client using the ALTO Endpoint Multi-Cost information. However common sense lead to warn that a necessary condition for methods that rank vectors to be reliable is that the components (costs) of the processed vectors be numerical Cost Mode. Randriamasy & Schwan Expires May 3, 2012 [Page 17] Internet-Draft Multi-Cost ALTO October 2011 This Service introduces a new media type to define the service and the input parameters. 4.4.1. Endpoint Multi-Cost The Endpoint Multi-Cost resource provides information about multiple costs between individual endpoints. This service MAY be provided by an ALTO Server. If it is provided. It is important to note that although this resource allows an ALTO Server to reveal costs between individual endpoints, an ALTO Server is not required to do so. A simple alternative would be to compute the cost between two endpoints as the cost between the PIDs corresponding to the endpoints +++ if this service is available for the requested Cost Types +++ . See Section 12.1 for additional details. 4.4.2. Media Type The media type is "application/alto-endpointmulticost+json". 4.4.3. HTTP Method This resource is requested using the HTTP POST method 4.4.4. Input Parameters Input parameters are supplied in the entity body of the POST request. This document specifies input parameters with a data format indicated by media type "application/alto-endpointmulticostparams+json", which is a JSON Object of type ReqEndpointMultiCostMap: object { TypedEndpointAddr srcs<0..*>; [OPTIONAL] TypedEndpointAddr dsts<1..*>; } EndpointFilter; object{ CostType cost-type<0..*>; CostMode cost-mode<0..*>; JSONString constraints; [OPTIONAL] EndpointFilter endpoints; } ReqEndpointMultiCostMap; with members: Randriamasy & Schwan Expires May 3, 2012 [Page 18] Internet-Draft Multi-Cost ALTO October 2011 cost-mode The Cost Mode ( Section 5.1.2) to use for returne costs that are encoded with the 'JSONnumber' type. For Multi-Cost requests this Cost Mode MUST be numerical for any Cost Type encoded with the 'JSONnumber' type, provided that the Cost Mode 'numerical' is available for this Cost Type. Remember (Section 5.1.2) that ALTO Clients SHOULD be cognizant of operations applicable to different Cost Modes. cost-type The Cost Type ( Section 5.1.1) to use for returned costs. All the listed the Cost Types MUST be indicated in this resource's capabilities ( Section 7.7.5.1.4). constraints Defined equivalently to the "constraints" input parameter of a Filtered Multi Cost Map (see Section 7.7.3.2). endpoints A list of Source Endpoints and Destination Endpoints for which Path Costs are to be returned. If the list of Source Endpoints is empty (or not included), the ALTO Server MUST interpret it as if it contained the Endpoint Address corresponding to the client IP address from the incoming connection (see Section 10.3 for discussion and considerations regarding this mode). The list of destination Endpoints MUST NOT be empty. The ALTO Server MUST interpret entries appearing multiple times in a list as if they appeared only once. 4.4.5. Capabilities See section 4.3.4 of this draft. 4.4.6. Response TBC The returned InfoResourceEntity object has "data" member equal to InfoResourceEndpointMultiCostMap, where: Randriamasy & Schwan Expires May 3, 2012 [Page 19] Internet-Draft Multi-Cost ALTO October 2011 object EndpointDstMultiCosts { JSONArray [TypedEndpointAddr]; ... }; object { EndpointDstMultiCosts [TypedEndpointAddr]<0..*>; ... } EndpointMultiCostMapData; object { CostMode cost-mode<0..*>; CostType cost-type<0..*>; EndpointMultiCostMapData map; } InfoResourceEndpointMultiCostMap; InfoResourceEndpointMultiCostMap has members: cost-type<0..*> The Cost Types used in the returned Cost Map. cost-mode<0..*> The Cost Mode for each of the Cost Types used in the returned Cost Map. map The Endpoint Multi-Cost Map data itself. EndpointMultiCostMapData is a JSON object with each member representing a single Source Endpoint specified in the input parameters; the name for a member is the TypedEndpointAddr string identifying the corresponding Source Endpoint. For each Source Endpoint, a EndpointDstMultiCosts object denotes the cost vector associated to each Destination Endpoint specified in the input parameters; the name for each member in the object is the TypedEndpointAddr string identifying the corresponding Destination Endpoint. 4.4.7. Example Randriamasy & Schwan Expires May 3, 2012 [Page 20] Internet-Draft Multi-Cost ALTO October 2011 POST /endpointcost/lookup HTTP/1.1 Host: alto.example.com Content-Length: [TODO] Content-Type: application/alto-endpointmulticostparams+json Accept: application/alto-endpointmulticost+json,application/alto-error+json { "cost-type" : ["routingcost", "hopcount"], "cost-mode" : ["numerical", "numerical"], "endpoints" : { "srcs": [ "ipv4:192.0.2.2" ], "dsts": [ "ipv4:192.0.2.89", "ipv4:198.51.100.34", "ipv4:203.0.113.45" ] } } HTTP/1.1 200 OK Content-Length: [TODO] Content-Type: application/alto-endpointmulticost+json { "meta" : {}, "data" : { "cost-type" : ["routingcost", "hopcount"], "cost-mode" : ["numerical", "numerical"], "map" : { "ipv4:192.0.2.2": { "ipv4:192.0.2.89" : [1, 7], "ipv4:198.51.100.34" : [2, 4], "ipv4:203.0.113.45" : [3, 2] } } } } 4.5. ALTO Status Codes for Multi-Cost ALTO If the Multi-cost Service is not supported for either the Cost Map or the Endpoint Service, then the ALTO server sends an ALTO status code 7 corresponding to HTTP status code 501 indicating "Invalid cost structure". The ALTO client may then needs to place as many requests as needed Cost Types, and the ALTO server sends as many cost maps or Randriamasy & Schwan Expires May 3, 2012 [Page 21] Internet-Draft Multi-Cost ALTO October 2011 EP cost as needed. To the attribute Cost Mode in S.5.1 should be associated a rule stipulating that when multiple cost types are requested, then the requested Cost Mode SHOULD be numerical. 5. Use cases for further Cost Types and Endpoint Properties The current ALTO protocol [ID-alto-protocol] specification requests the creation of two registries maintained by IANA. The ALTO Cost Type registry ensures that the Cost Types that are represented by an ALTO Cost Map are unique identifiers, and it further contains references to the semantics of the Cost Type. The current specification registers 'routingcost' as a generic measure for routing traffic from a source to a destination. In a similar way the ALTO Endpoint Property Registry ensures uniqueness of ALTO Endpoint Property identifiers and provides references to particular semantics of the allocated Enpoint Properties. Currently the 'pid' identifier is registered, which serves as an identifier that allows aggregation of network endpoints into network regions. Both registries accept new entries after Expert Review [[ID-alto-protocol]]. New entries are requested to be conform to the respective syntactical requirements, and must include information about the new identifier, the intended semantics as well as security considerations. The current protocol specification concentrates on the basic use case of optimizing routing costs in NSPs networks. Upcoming use cases however will require both, new Cost Types and new Endpoint Properties. The goal of this section is to describe further forward looking use case scenarios that are likely to benefit from ALTO, and, in future iterations, to convey new Cost Types and Endpoint Properties that are likely to be beneficial for ALTO clients in these scenarios. 5.1. Delay Sensitive Overlay Applications The ALTO working group has been created to allow P2P applications and NSPs a mutual cooperation, in particular because P2P bulk file- transfer applications have created a huge amount of intra-domain and congestion on low-speed uplink traffic. By aligning overlay topologies according to the 'routingcost' of the underlying network both layers are expected to benefit in terms of reduced costs and improved Quality-of-Experience. However other types of overlay applications might benefit from a different set of path metrics. In particular for real-time sensitive applications, such as gaming, interactive video conferencing or Randriamasy & Schwan Expires May 3, 2012 [Page 22] Internet-Draft Multi-Cost ALTO October 2011 medical services, creating an overlay topology with respect to a minimized delay is preferable. However it is very hard for a NSP to give accurate guidance for this kind of realtime information, instead probing through end-to-end measurements on the application layer has proven to be the superior mechanism. Still, a NSP might give some guidance to the overlay application, for example by providing statistically preferable paths with respect to the time of a day. Also static information like hopcount can be seen as an indicator for the delay that can be expected. In the following iterations this draft will thus analyse which metrics can realistically be provided through ALTO to give delay sensitive applications guidance for peer selection. 5.2. CDN Surrogate Selection A second use case is motivated through draft [draft-jenkins-alto-cdn-use-cases-01]. The request router in today's CDNs makes a decision about to which surrogate or cache node a content request should be forwarded to. Typically this decision is based on locality aspects, i.e. the surrogate node which is closest to the client is preferred by the request router. An ALTO server hereby is one promising option to allow NSPs to give guidance to the CDN about which cache node would be preferable according to the view of the network by the 'routingcost' Cost Type. Providing this kind of information is in particular important as one trend is to place cache nodes deeper into the network (i.e., closer to the end user), which results in the need for finer grained information. While distance today is the predominant metric used for routing decisions, other metrics might allow sophisticated request routing strategies. For example the load a cache node sees in terms of CPU utilization, memory usage or bandwidth utilization might influence routing decisions for load-balancing reasons. There exist numerous ways of gathering and feeding this kind of information into the request routing mechanism. Typically, information reporting on the occupation of a cache could be based on: o an Endpoint Property called : "EPCapacity" and reflecting the nominal capacity of this endpoint. This capacity could be splitted in: * EP Nominal Memory : denoting the nominal storage capacity * EP Nominal Bandwidth: denoting the computation resources of the Endpoint. Randriamasy & Schwan Expires May 3, 2012 [Page 23] Internet-Draft Multi-Cost ALTO October 2011 o an Endpoint Cost called: "EP occupied Capacity" and reflecting the currently available resources wrt their nominal capacity and splitted in the same way as for the EP Capacity: * EP Occupied Memory: denoting the remaining storage capacity, * EP Occupied Bandwidth: denoting the remaining computation resources. As ALTO is likely to become a standardized interface to provide network topology information, for simplicity other information that is used by a request router could be provided by the ALTO server as well. In the next iterations of this draft we will analyse which of these metrics is suitable to be provided as Cost Type or Endpoint Property for the use case of CDN Surrogate Selection and propose to register them in the respective registries. 6. Proposed additional Properties and Costs This section proposes further extensions on new Costs Types, to be discussed in the WG. 6.1. The Path Occupation Cost 6.2. For further extensions: dynamic Costs It is agreed in the ALTO requirements that: "information that can change very rapidly, such as transport-layer congestion, is out of scope for an ALTO service. Such information is better suited to be transferred through an in-band technique at the transport layer instead". However NP managing ALTO Servers as well as Application Client using ALTO information have common interests to use some information on time (or space) varying information that is not provided in real time, which is neither desirable nor feasible, but rather a synthetis of such information. Such information is made available for ALTO Servers in order to reflect how the NP wishes the information to be used by the Applicaton Client. One example of such information is the path bandwidth. This can be captured in real time by end systems, in terms of transmission rate. On the other hand, the NP can formulate preferences on given paths, given the experienced traffic volume at given time periods on given time scales. One way for the NSP to provide guidance on highly dynamic network state information such as delay and load while preserving confidentiality and moderating processing load, is to provide them in Randriamasy & Schwan Expires May 3, 2012 [Page 24] Internet-Draft Multi-Cost ALTO October 2011 a synthetic or abstract form, for example as a numerical indicator. It is important to have the possibility to reflect that the provided values are applicable for a given time period, for example busy hours or days, and are subject to changes over time. Also, how the NP has evaluated the cost associated to a given network state information is out of scope ot the ALTO protocol. The usage of a time related cost is more proactive in that it can be used like a "time table" to figure out the best time to schedule data transfer and also anticipate predictable events including predictable flash crowds. The time-related information is not necessarily historical and statistic. This is why the term synthetic or abstraction is more suitable than the term statistic. 6.2.1. Dynamic Cost Attributes For further extensions, specifications around "dynamic" costs are proposed and will be completed in further versions of this draft. 6.2.1.1. The dynamic Cost Mode The "dynamic" mode applies to Costs that are eligible for the "numerical" Cost Mode and can also be expressed as such. In that sense, the "dynamic" mode is an extension of the "numerical" mode. Example are "pathoccupationcost" and "pathlosscost" that respectively report on the occupied bandwidth and packet loss on a path. Other Cost Types such as JSONBool could also claim the "dynamic" mode, as states may be "true" or "false" depending on given periods. To stick to the target usage of Costs which is to be integrated in some evaluation process, an alternative could be to assign a numerical value to boolean costs and carefully map "true" and "false" with values '0' and '1'. 6.2.2. Proposed dynamic Cost Scope capability To ensure that the Application Client uses the NP provided information on dynamic Costs in an inambuguous way, a capability called Cost Scope is introduced here, to report on the validity of the "dynamic" cost values. This draft focuses on the time related scope. Indeed, one may as well imagine some costs proposed in the future that could also be scoped w.r.t. space. o Unit: ranging from "seconds" to "year", expresses the granularity of the information, o Size: the scope of the dynamic cost, that is the number of units of the dynamic cost sample, Randriamasy & Schwan Expires May 3, 2012 [Page 25] Internet-Draft Multi-Cost ALTO October 2011 o Reference time, o Begin: the index of the first unit in the sample, o Next update: the date at which the sample will be re-computed, o Last update: the last re-computation day. Attributes 'Last update 'and 'Next update' report on the update frequency and age of the information. 6.2.2.1. Example of time scope for a dynamic cost An example is: a metric called 'pathoccupationcost' (POC for short) is computed with a granularity of 2 hours, starting a 0h00, for 24 hours, with reference time GMT. The goal is to enable applications to see which time intervals in a day are the most favorable to operate. 6.2.3. Example of dynamic information resources in the IRD The example IRD given in Section 4.1.1 includes an URI called "http://custom.alto.example.com/multi/endpointmulticost/lookup", in which the ALTO Server provides additional Mutliple Endpoint Costs including a Cost called "pathoccupationcost" for which the Cost Mode is "dynamic". This resource is accessible with other costs, via a separate subdomain called "custom.alto.example.com". The Endpoint Costs available via this subdomain are the "hopcount", "routingcost" and "pathoccupationcost" Cost Types, with the two first ones in the "numerical" Cost Mode and "pathoccupationcost" in the "dynamic" cost mode. An ALTO Client can discover the services available by "custom.alto.example.com" by successfully performing an OPTIONS request to "http://custom.alto.example.com/multi/endpointmulticost". Randriamasy & Schwan Expires May 3, 2012 [Page 26] Internet-Draft Multi-Cost ALTO October 2011 OPTIONS /multi/endpointmulticost HTTP/1.1 Host: custom.alto.example.com Accept: application/alto-directory+json,application/alto-error+json HTTP/1.1 200 OK Content-Length: [TODO] Content-Type: application/alto-directory+json { "resources" : [ { "uri" : "http://custom.alto.example.com/multi/endpointmulticost", "media-types" : [ "application/alto-endpointmulticost+json" ], "accepts" : [ "application/alto-endpointmulticostparams+json" ], "capabilities" : { "cost-constraints" : true, "cost-modes" : [ "numerical", "numerical", "dynamic" ], "cost-types" : [ "routingcost", "hopcount", "pathoccupationcost" ], "cost-scope": [ "permanent", "permanent", {"unit": "hour", "size": 24, "begin": 0, "lastupdate": mm/hh/dd/mm/yyyy, "nextupdate": mm/hh/dd/mm/yyyy} ] } } ] } 7. IANA Considerations Information for the ALTO Endpoint property registry maintained by the IANA and related to the new Endpoints supported by the acting ALTO server. These definitions will be formulated according to the syntax defined in Section on "ALTO Endpoint Property Registry" of [ID-alto-protocol], Information for the ALTO Cost Type Registry maintained by the IANA and related to the new Cost Types supported by the acting ALTO server. These definitions will be formulated according to the syntax defined in Section on "ALTO Cost Type Registry" of [ID-alto-protocol], Randriamasy & Schwan Expires May 3, 2012 [Page 27] Internet-Draft Multi-Cost ALTO October 2011 7.1. Information for IANA on proposed Cost Types When a new ALTO Cost Type is defined, accepted by the ALTO working group and requests for IANA registration MUST include the following information, detailed in Section 11.2: Identifier, Intended Semantics, Security Considerations. 7.2. Information for IANA on proposed Endpoint Propeeries Likewise, an ALTO Endpoint Property Registry could serve the same purposes as the ALTO Cost Type registry. Application to IANA registration for Endpoint Properties would follow a similar process. 8. Acknowledgements Thank you to Dave Mac Dysan (Verizon) for fruitful discussions and comments on the last draft. Sabine Randriamasy is partially supported by the MEDIEVAL project (http://www.ict-medieval.eu/), a research project supported by the European Commission under its 7th Framework Program (contract no. 248565). The views and conclusions contained herein are those of the authors and should not be interpreted as necessarily representing the official policies or endorsements, either expressed or implied, of the MEDIEVAL project or the European Commission. Nico Schwan is partially supported by the ENVISION project (http://www.envision-project.org), a research project supported by the European Commission under its 7th Framework Program (contract no. 248565). The views and conclusions contained herein are those of the authors and should not be interpreted as necessarily representing the official policies or endorsements, either expressed or implied, of the ENVISION project or the European Commission. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5693] "Application Layer Traffic Optimization (ALTO) Problem Statement", October 2009. Randriamasy & Schwan Expires May 3, 2012 [Page 28] Internet-Draft Multi-Cost ALTO October 2011 9.2. Informative References [ID-ALTO-Requirements7] "draft-ietf-alto-reqs-07.txt", January 2011. [ID-alto-protocol] , Eds., ""ALTO Protocol" draft-ietf-alto-protocol-09.txt", June 2011. [draft-jenkins-alto-cdn-use-cases-01] ""Use Cases for ALTO within CDNs" draft-jenkins-alto-cdn-use-cases-01", June 2011. Authors' Addresses Sabine Randriamasy (editor) Alcatel-Lucent Bell Labs Route de Villejust NOZAY 91460 FRANCE Email: Sabine.Randriamasy@alcatel-lucent.com Nico Schwan Alcatel-Lucent Bell Labs Lorenzstrasse 10 STUTTGART 70435 GERMANY Email: Nico.Schwan@alcatel-lucent.com Randriamasy & Schwan Expires May 3, 2012 [Page 29]