Network Working Group S. Randriamasy, Ed. Internet-Draft Alcatel-Lucent Bell Labs Intended status: Experimental N. Schwan Expires: January 12, 2012 July 11, 2011 Multi-Cost ALTO draft-randriamasy-alto-multi-cost-03 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 by providing a better mapping of the Selected Endpoints to needs of the growing diversity of Content Networking Applications and to the network conditions, secondly by producing a more robust choice of multiple Endpoints, helping thus out for efficient Multi-Path transfer. 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 and focus on the Endpoint Cost Service. The second part proposes two use cases motivating further definitions of additional CostTypes and Cost Attributes related to timeframe and validity period. 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. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute Randriamasy & Schwan Expires January 12, 2012 [Page 1] Internet-Draft multi-cost ALTO July 2011 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 January 12, 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 January 12, 2012 [Page 2] Internet-Draft multi-cost ALTO July 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Proposed ALTO protocol updates for multi-cost transactions . . 6 4.1. Multi-Cost Map Service . . . . . . . . . . . . . . . . . . 6 4.1.1. Media Type . . . . . . . . . . . . . . . . . . . . . . 6 4.1.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . 7 4.1.3. Input Parameters . . . . . . . . . . . . . . . . . . . 7 4.1.4. Capabilities . . . . . . . . . . . . . . . . . . . . . 7 4.1.5. Response . . . . . . . . . . . . . . . . . . . . . . . 7 4.1.6. Example . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. Endpoint Multi-Cost Service . . . . . . . . . . . . . . . 7 4.2.1. Media Type . . . . . . . . . . . . . . . . . . . . . . 7 4.2.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . 7 4.2.3. Input Parameters . . . . . . . . . . . . . . . . . . . 7 4.2.4. Capabilities . . . . . . . . . . . . . . . . . . . . . 8 4.2.5. Response . . . . . . . . . . . . . . . . . . . . . . . 8 4.2.6. Example . . . . . . . . . . . . . . . . . . . . . . . 8 4.3. ALTO Status Codes for Multi-Cost ALTO . . . . . . . . . . 8 5. Use cases for further Cost Types and Endpoint Properties . . . 8 5.1. Delay Sensitive Overlay Applications . . . . . . . . . . . 9 5.2. CDN Surrogate Selection . . . . . . . . . . . . . . . . . 10 6. Proposed additional Properties and Costs . . . . . . . . . . . 10 6.1. Scoping ALTO information . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7.1. Information for IANA on proposed Cost Types . . . . . . . 11 7.2. Information for IANA on proposed Endpoint Propeeries . . . 11 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 9.2. Informative References . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Randriamasy & Schwan Expires January 12, 2012 [Page 3] Internet-Draft multi-cost ALTO July 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 (see S.7.7.4.1). However section 7.7.3.2 on Cost Map states about both parameters Cost Type and Cost Mode that: "This parameter MUST NOT be specified multiple times". The ALTO requirements draft, see [ID-ALTO-Requirements7] also 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 altogether. Currently, the costs are provided in a scalar form, one by one. So that an ALTO Client wanting information for several Cost Types must place a request and receive a response as many times as desired Cost Types. However, vector costs provide a robust and natural input to multi-path connections and getting all costs in one single query/ response transaction saves time and ALTO traffic, thus ressources, thus energy. The ALTO Problem Statement, see [RFC5693] and the ALTO requirements draft, see [RFC5693] stress 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", as "ALTO is not an admission control system "and does not necessarily know about the instant load of endpoints and links. However, longer term statistics or empirical ratings on performance oriented information may still be useful for a reliable choice of candidate endpoints. In addition, given the QoE requirements of nowadays and Randriamasy & Schwan Expires January 12, 2012 [Page 4] Internet-Draft multi-cost ALTO July 2011 future Internet applications, more and more NPs compute and store such information to optimize their traffic. Last, specific ALTO servers can be specified for mobile core networks, which have a smaller scale and can afford and take advantage of using smaller 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. Besides, keeping the shortest or cheapest possible path, in addition, saves resources, time and energy. 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. For P2P applications, the use case where the ALTO Client is embedded in the P2P tracker is also applicable. 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. The solution proposed in this draft is applicable to fixed networks. It is also meant for smaller networks such as mobile networks. 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: includes both ISPs, who provide means 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. Randriamasy & Schwan Expires January 12, 2012 [Page 5] Internet-Draft multi-cost ALTO July 2011 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 is to be completed and proposes first updates of the ALTO protocol to support Multi Cost ALTO Services or provide additional ALTO information. It integrates discussions on he ALTO mailing list and its goal is to initiate further discussions and protocol update proposals. 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 correspondence between the components and the cost types MUST be indicated in the ALTO request. The ALTO server then, provided it supports the desired cost, 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, whose component each 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 ALTO services impacted by the Multi-Cost extensions are: o Information Resources Directory, o Cost Map Service, o Cost Map Filtering Service, o Endpoint Cost Lookup Service. This draft focuses on the case of the Endpoint Cost Lookup Service 4.1. Multi-Cost Map Service To be completed 4.1.1. Media Type Randriamasy & Schwan Expires January 12, 2012 [Page 6] Internet-Draft multi-cost ALTO July 2011 4.1.2. HTTP Method This resource is requested using the HTTP POST method 4.1.3. Input Parameters 4.1.4. Capabilities 4.1.5. Response 4.1.6. Example 4.2. Endpoint Multi-Cost Service 4.2.1. Media Type 4.2.2. HTTP Method This resource is requested using the HTTP POST method 4.2.3. 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-endpointcostparams+json", which is a JSON Object of type ReqEndpointCostMap: object { TypedEndpointAddr srcs<0..*>; [OPTIONAL] TypedEndpointAddr dsts<1..*>; } EndpointFilter; object { CostMode cost-mode; CostType cost-type<1..*>; JSONString constraints; [OPTIONAL] EndpointFilter endpoints; } ReqEndpointCostMap; with members: Randriamasy & Schwan Expires January 12, 2012 [Page 7] Internet-Draft multi-cost ALTO July 2011 cost-mode The Cost Mode ( Section 5.1.2) to use for returned costs. For Multi-Cost requests this Cost Mode SHOULD be numerical. 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 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 Alimi, et al. Expires December 29, 2011 [Page 50] Internet-Draft ALTO Protocol June 2011 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.2.4. Capabilities 4.2.5. Response 4.2.6. Example 4.3. 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 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 Randriamasy & Schwan Expires January 12, 2012 [Page 8] Internet-Draft multi-cost ALTO July 2011 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 uniquenes 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 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 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 statisically 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 realisticaly be provided through ALTO to give delay sensitive applications guidance for peer selection. Randriamasy & Schwan Expires January 12, 2012 [Page 9] Internet-Draft multi-cost ALTO July 2011 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, 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. 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 To be further specified 6.1. Scoping ALTO information One way for the NSP to provide guidance on highly dynamic network state information such as delay and load is to provide them in the form of statistics or as a numerical coarse grain indicator. It is important to have the possibility to reflect that the provided values are applicable for a given time period, for example business hours, and are subject to changes over time. The following attributes can be associated to the applicable ALTO information: Randriamasy & Schwan Expires January 12, 2012 [Page 10] Internet-Draft multi-cost ALTO July 2011 o an age attribute indicating when the information was generated. o for statistical costs a time period attribute indicating over which duration the statistics were collected. o a validity attribute indicating when the provided values should be refreshed. By defaut, this parameter can be set to infinity. 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], 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 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 Randriamasy & Schwan Expires January 12, 2012 [Page 11] Internet-Draft multi-cost ALTO July 2011 (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. 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 Randriamasy & Schwan Expires January 12, 2012 [Page 12] Internet-Draft multi-cost ALTO July 2011 Nico Schwan Phone: Fax: Email: URI: Randriamasy & Schwan Expires January 12, 2012 [Page 13]