ALTO Working Group Z. Despotovic, W. Kellerer Internet Draft DOCOMO Euro-Labs Intended status: Standards Track S. Spirou Expires: January 2010 Intracom Telecom D. Staehle University of Wuerzburg M. A. C. Rodriguez Telefonica I+D I. Papafili AUEB July 6, 2009 ALTO-FCP: Application Layer Traffic Optimization Feedback-Based Client Protocol draft-despotovic-alto-feedback-cp-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on January 6, 2009. Copyright Notice Copyright (c) 2009 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 in effect on the date of Despotovic, et al. Expires January 6, 2010 [Page 1] Internet-Draft ALTO-FCP July 2009 publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Despotovic, et al. Expires January 6, 2010 [Page 2] Internet-Draft ALTO-FCP July 2009 Abstract In some networked applications, such as peer-to-peer file sharing, the same resource (e.g., a file or a server process) is available at several potential resource providers. Resource consumers typically try to select providers so that application performance is improved, establishing an overlay topology of direct logical links in the process. However, lack of reliable information about the underlying network can lead to poor choices and suboptimal application performance. In addition, resulting application traffic is largely oblivious to technical, economical, and political constraints at the network level, causing problems for network operators. This document describes a protocol that facilitates the exchange of information between an overlay and the underlying network. Such information can be used at each layer to make decisions that are not detrimental to the other layer or, ideally, are beneficial to both. Despotovic, et al. Expires January 6, 2010 [Page 3] Internet-Draft ALTO-FCP July 2009 Table of Contents 1. Introduction ................................................ 5 2. Conventions ................................................. 7 3. Architecture ................................................ 8 4. Protocol ................................................... 10 4.1. Messages .............................................. 10 4.1.1. Capabilities ..................................... 10 4.1.2. Guidance ......................................... 11 4.1.3. Evaluation........................................ 12 4.2. Additional capabilities of an ALTO server ............. 13 5. Security Considerations .................................... 14 6. IANA Considerations ........................................ 15 7. References ................................................. 16 7.1. Normative References .................................. 16 7.2. Informative References ................................ 16 8. Acknowledgments ............................................ 17 Despotovic, et al. Expires January 6, 2010 [Page 4] Internet-Draft ALTO-FCP July 2009 1. Introduction Overlay Applications such as P2P file sharing and video streaming generate a significant portion of today's Internet traffic and will most likely remain dominant consumers of network resources in the Future Internet as well. Such applications pose a problem for the network operators (equivalently, Internet service providers - ISPs) as they do not take into account the underlying network topology in their overlay connection establishment and overlay routing decisions. The continuous change of P2P traffic matrices renders such traffic very expensive for ISPs, since it affects the interconnection relations with other ISPs. Traditional traffic management approaches usually fail for P2P traffic, since overlays establish multiple connections between peers, change their structure dynamically, span across several ISPs, and masquerade their presence. Facing these facts, ISPs do whatever they can to lower the costs imposed by P2P applications. Some of these attempts are not efficient and also not well received by the public. Operating an overlay network unaware of the underlying network has also negative impact on the users of overlay applications. For example, users of P2P file distribution applications might experience shorter download times if overlay network connections are established with the physical network topology in mind. Users of P2P video streaming applications might experience shorter stall times if overlay network connections are established along physical links with shorter delays. This document assumes a framework where an ALTO Service running in the network allows both overlay application users and ISPs to benefit from exchanging relevant information they own. It further proposes that ISPs should operate an ALTO Service through which they should increase both the performance of P2P applications and the efficiency of their own operation. As suggested in [I-D.ietf-alto-problem- statement], revealing (at least in part) the underlying network information to the P2P overlay applications allows a range of operating points in which both ISPs and overlay application users are better off than before, i.e., when overlay applications operate oblivious of the underlying network. This document describes a protocol that facilitates the exchange of information between overlay application entities and the ISPs. Such information can be used at each side to make decisions that are beneficial to both, or at least do not harm the other one. The key aspects of the protocol are the following: Despotovic, et al. Expires January 6, 2010 [Page 5] Internet-Draft ALTO-FCP July 2009 o Negotiation between the ALTO Client and the ALTO Server allowing the two parties to gradually reveal more information and find their best tradeoffs between the revealed information and performance gains. o Feedback submission from an ALTO Client to an ALTO Server with the goal of improving the ALTO Server's operation in the future. More precisely, performance reporting from the ALTO Client to the ALTO Server should give the Server an opportunity to learn about conditions in remote parts of the Internet and thus improve its recommendations with time. Equally important, the ALTO Server can through these performance reports learn about new applications, i.e., how to guide the Clients running these applications. The rest of the document is structured as follows: section 3 provides the architectural context and section 4 discusses the protocol. Despotovic, et al. Expires January 6, 2010 [Page 6] Internet-Draft ALTO-FCP July 2009 2. Conventions 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]. Several terms used in this document have special meaning in the context of ALTO. These terms are defined in [I-D.ietf-alto-problem- statement]. Despotovic, et al. Expires January 6, 2010 [Page 7] Internet-Draft ALTO-FCP July 2009 3. Architecture In order to provide information about the underlying network, the ALTO Service can access and expose to ALTO Clients (parts of) the routing information available for example within the BGP routing protocol executed by the ISP running the service. This is what [I- D.bgp-based-alto-service], an informational draft accompanying this document, proposes. BGP routing tables can be used to provide locality indications to the Peers. Other policies found in the BGP tables are also used. In summary, [I-D.bgp-based-alto-service] uses all information available in BGP routing tables to rate IP addresses sent by the ALTO Client and guide the overlay connection establishment so that both the ISP and the overlay application benefit. Extensions that further use intra-domain information available in the BGP protocol are also possible, although they are not considered at the moment. ALTO +------+ SERVER 1 +-----+ | Peers +-----+ +------+ +=====| |--+ | |........| |====+ +--*--+ +-----+ +------+ | * Source 1 of / | * topological / | +--*--+ information / +=====| | Resource Directory / +-----+ (Tracker, proxy) / / +------+ / +-----+ | Peers +-----+ +------+ +=====| |--+ | |........| |====+ +--*--+ +-----+ +------+ | * Source 2 of ALTO | * topological SERVER 2 | +--*--+ information +=====| | Resource Directory +-----+ (Tracker, proxy) Legend: === ALTO Client protocol *** Application protocol (out of scope) ... Provisioning or initialization (out of scope) /// Inter-ALTO Server protocol Figure 1: ALTO Protocol Architecture Despotovic, et al. Expires January 6, 2010 [Page 8] Internet-Draft ALTO-FCP July 2009 Figure 1 illustrates the architecture that this document follows. Apart from proposing a specific ALTO Client-Server protocol, a side goal of this document is to also emphasize the importance of communication between ALTO Servers. From this perspective, the information BGP and other IGP routing protocols provide can be seen here as an important ingredient of such a future inter-ALTO Server protocol. The introduction of the ALTO Service requires the voluntary participation of both the overlay application user and the ALTO Service provider. As pointed out in Section 1, the ISP's incentive to run an ALTO service is an optimized traffic pattern that reduces costs for inter-domain and maybe also for intra-domain traffic. A user's incentive to install an ALTO Client is an improved application performance. However, studies [ChBu08, BiCa06] show that the advantages of an ALTO Service are more on the ISP than on the Client side. In case of BitTorrent, a significant improvement in the Client performance is only observed if the bottleneck is in the inter-domain links. However, when this is not the case, ISPs must look for alternative sources of incentives for the users to follow the guidance suggested by the ALTO Service. One such source might be the ISP's promise to prioritize the traffic of those users who follow the ALTO Service guidance. As such, the ALTO Service can be used not only for providing information about the underlying network (closest resources, congested links, etc.) but it could also enforce different policies in the network in order to improve the network performance guarantees for specific flows or for intra-domain traffic. The principle idea is to have a normal ALTO Server that assists the users in choosing their resource providers (Peers or mirror servers) such that the selection is better than random and also in the interest of the ISP running the ALTO Service. In exchange for the Client's following the suggested guidance, the ISP may introduce a traffic class "compliant best effort" which comprises all the traffic that follows the guidance of the ALTO Server and is prioritized versus best effort traffic or it could provide more bandwidth. For these purposes, the ALTO Server could be enhanced by interfacing with the Network Management Systems (NMS) of the ISP's network that are usually able to enforce such policies. Despotovic, et al. Expires January 6, 2010 [Page 9] Internet-Draft ALTO-FCP July 2009 4. Protocol The main contribution of this draft is an ALTO Client-Server protocol, termed Application Layer Traffic Optimization Feedback- Enhanced Client Protocol (ALTO-FCP) and specifically designed to fit the architecture just presented and fulfill the goals set in the Introduction. ALTO-FCP follows the request/response message exchange pattern between ALTO Clients and ALTO Servers. The eight main ALTO- FCP messages are: the Capabilities Query, the Capabilities Response, the Guidance Query, the Guidance Response, the Evaluation Request, the Evaluation Offer, the Evaluation Query, and the Evaluation Report. Given a choice of ALTO Services, an ALTO Client MAY send a Capabilities Query to each Service for discovering how much it can assist in Resource Provider selection. ALTO Servers which are in a position to reply MAY send back a Capabilities Response, providing details of their rating skills. The Client selects an appropriate subset of Servers and MUST then send a Guidance Query to each for requesting ratings on a set of HLAs (Host Location Attribute, see [I- D.ietf-alto-problem-statement]) transmitted with the Query. The Client MAY also submit information that could guide the Server in generating more specific ratings. Each Server considers the request and SHOULD reply with a Guidance Response that mainly includes ratings on the HLAs. A Server MAY send an Evaluation Request to a subset of previously guided Clients for discovering if and how they can provide feedback. Contacted Clients SHOULD respond to the Server with Evaluation Offers, detailing their feedback skills in terms of application performance metrics. A Server SHOULD then respond with an Evaluation Query, specifying the interesting performance metrics. Clients SHOULD send back an Evaluation Report with the measured performance metrics for previously rated HLAs. 4.1. Messages 4.1.1. Capabilities Capabilities Query (CQ): An ALTO Client seeking guidance in Resource Provider selection sends a CQ to one or more ALTO Servers to discover which rating criteria are supported and at which accuracy level. Each contacted Server SHOULD belong to a different ALTO Service. Servers belonging to the same Service SHOULD be contacted through the ALTO Service. ALTO Services and Servers are discovered through mechanisms external to ALTO-FCP (e.g., [I-D.song-alto-server-discovery]). A CQ Despotovic, et al. Expires January 6, 2010 [Page 10] Internet-Draft ALTO-FCP July 2009 MAY include desired rating criteria and accuracy levels, so that the ALTO Client can make a more informed selection among Servers. Capabilities Response (CR): An ALTO Server sends a CR to an ALTO Client as a normal response to an earlier CQ. If the CQ was minimal, the CR SHOULD include all supported rating criteria and maximum accuracy levels. If the CQ identified options, the CR MUST NOT include supported rating criteria that were not identified in the CQ options. Similarly, the CR MUST NOT include supported rating criteria with maximum accuracy levels that are below those identified in the CQ options. 4.1.2. Guidance Guidance Query (GQ): An ALTO Client sends a GQ to an ALTO Server to request guidance in Resource Provider selection. A GQ MUST include a set of HLAs (Host Location Attribute, see [I-D.ietf-alto-problem-statement]) that the Client has obtained through Application mechanisms. This HLA set represents potential Resource Providers for which the Client seeks ratings. To direct the Server in generating the ratings, a GQ MAY include a set of rating criteria. In this case, a GQ MAY in addition identify the desired accuracy level and the relative importance of each criterion. A Client MAY also request rating criteria values to be provided for each HLA, so that Resource Provider selection can be more informed. In further assistance of rating generation, a GQ MAY include the Application type, e.g., file sharing, media streaming, etc. A Client MAY send a GQ for the same HLA set to a subset of the Servers identified earlier through a Capabilities Query/Response conversation, but possibly with different options. A Client MAY also request the Server to rate HLAs for each of the provided rating criteria separately. In that case the Server MUST send back a list of ratings for each criterion. The Client's rationale for doing so can be better optimization or to keep the application objective shielded from the Server. When an ALTO Client is not satisfied with the response from an ALTO Server and it believes that the source of problem was too broad HLAs or missing options, the Client MAY send a refinement of the previously sent GQ. This can lead to a sequence of GQ/GR messages. Despotovic, et al. Expires January 6, 2010 [Page 11] Internet-Draft ALTO-FCP July 2009 Guidance Response (GR): A GR is sent from an ALTO Server to an ALTO Client as a normal response to an earlier GQ. A GR SHOULD provide a rating for each HLA in the associated GQ. If the Server is unable to provide a rating for an HLA then any information about that HLA MUST be omitted from the GR. A Server MAY include in the GR the values of the rating criteria used during rating generation in order to further assist the Client in using the guidance. 4.1.3. Evaluation Client evaluation reporting is an OPTIONAL part of ALTO-FCP. The intention is to allow the ALTO Server to obtain feedback on the rated HLAs. This feedback is in the form of performance metrics (e.g., bandwidth estimates, round trip times, connection stability, etc.) that the Client measures while communicating with Peers at rated HLAs. The ALTO Server obtains evaluation reports from different Clients and can aggregate them to get a picture of HLA-HLA communication performance as seen by the Clients. The ALTO Server may then offer these HLA-HLA performance metrics as additional rating criteria to the ALTO Clients. The Client evaluation reporting messages are: Evaluation Request (ERQ): Possibly after a successful exchange of GQ/GR messages, an ALTO Server MAY send an ERQ to an ALTO Client requesting information on the Client's evaluation reporting capabilities. Evaluation Offer (EO): An ALTO Client SHOULD send an EO message to an ALTO Server as a normal response to an ERQ message. The EO identifies performance metrics that the Client can evaluate. An empty EO indicates that the Client does not support or is not willing to provide any performance metrics. Evaluation Query (EQ): An ALTO Server SHOULD send an EQ message as a normal response to a non-empty EO message. The ALTO Server MUST NOT send an EQ message following an empty EO message. The EQ identifies those performance metrics that the Server is actually interested in. The requested performance metrics MUST be a subset of the performance metrics offered in the EO message. Despotovic, et al. Expires January 6, 2010 [Page 12] Internet-Draft ALTO-FCP July 2009 Evaluation Report (ER): An ALTO Client SHOULD send an ER to an ALTO Server as a normal response to an earlier EQ message. The ER contains a list of HLAs and each HLA entry is associated with the evaluation of one or more performance metrics. The ALTO Server SHALL only consider the HLAs contained in earlier GRs. The reported performance metrics MUST be a subset of the performance metrics requested in the prior EQ. 4.2. Additional capabilities of an ALTO Server In case the ALTO Server also provides additional capabilities by interfacing the NMS (as explained in section 3) to, e.g., enforce a specific policy in the network, the ALTO server will build the GR considering the policies already applied in the network and it can also include an additional tag to show them. Moreover, the ALTO could offer all those capabilities as an additional service. Therefore, a new query-response transaction should be defined in order to allow the ALTO Client to identify the selected HLAs and the requested capacities and the ALTO Server should provide a response to show the result of the application of the new policies in the network (e.g., bandwidth available and guaranteed for the HLA-HLA connection). Despotovic, et al. Expires January 6, 2010 [Page 13] Internet-Draft ALTO-FCP July 2009 5. Security Considerations Queries, such as the CQ and the GQ, sent from ALTO Clients to ALTO Servers can become the vehicle for Denial of Service attacks. This may also hold for the EQ, sent from Servers to Clients. The ALTO Service and Application providers should consider these possibilities and strive for appropriate measures at each end. To prevent such attacks or also to ease privacy concerns that Applications and ISPs might have in revealing information, protocols such as SSL/TLS could be used orthogonally to ALTO-FCP, for security, integrity, and bilateral authentication. This might though require agreements and mechanisms at the business level. Despotovic, et al. Expires January 6, 2010 [Page 14] Internet-Draft ALTO-FCP July 2009 6. IANA Considerations None yet. Despotovic, et al. Expires January 6, 2010 [Page 15] Internet-Draft ALTO-FCP July 2009 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 7.2. Informative References [I-D.ietf-alto-problem-statement] Seedorf, J. and E. Burger, "Application-Layer Traffic Optimization (ALTO) Problem Statement", draft-ietf-alto-problem-statement-01 (work in progress), May 2009. [I-D.ietf-alto-reqs] Kiesel, S., Popkin, L., Previdi, S., Woundy, R., and Y. Yang, "Application-Layer Traffic Optimization (ALTO) Requirements", draft-ietf-alto-reqs-00 (work in progress), April 2009. [I-D.song-alto-server-discovery] Song, H., Even, R., Pascual, V., and R. Zhang, "Application-Layer Traffic Optimization (ALTO): Discover ALTO Servers", draft-song-alto-server-discovery-00 (work in progress), March 2009. [I-D.bgp-based-alto-service] Racz, P. and Z. Despotovic, "An ALTO Service based on BGP Routing Information", draft-racz-bgp- based-alto-service-00.txt (work in progress), May 2009. [BiCa06] Ruchir Bindal, Pei Cao, William Chan, Jan Medval, George Suwala, Tony Bates, and Amy Zhang, Improving Traffic Locality in BitTorrent via Biased Neighbor Selection, Proceedings of the 26th IEEE International Conference on Distributed Computing Systems, 2006 [ChBu08] David R. Choffnes and Fabian E. Bustamante, Taming the torrent: a practical approach to reducing cross-ISP traffic in Peer-to-Peer systems, SIGCOMM Comput. Commun. Rev., vol 38(4), 2008 Despotovic, et al. Expires January 6, 2010 [Page 16] Internet-Draft ALTO-FCP July 2009 8. Acknowledgments The authors are partially supported by the European Commission with the research project SmoothIT (Simple Economic Management Approaches of Overlay Traffic in Heterogeneous Internet Topologies) under the 7th Framework Programme. The authors are grateful to Fabio Hecht, Marcin Niemiec, and Krzysztof Wajda for their contribution and comments during the early stages of this work. Spiros Spirou would like to thank Michalis Makidis for fruitful discussions on the protocol messages. This document was prepared using 2-Word-v2.0.template.dot. Despotovic, et al. Expires January 6, 2010 [Page 17] Internet-Draft ALTO-FCP July 2009 Authors' Addresses Zoran Despotovic DOCOMO Euro-Labs Landsberger Strasse 312 Munich Germany Email: despotovic@docomolab-euro.com Wolfgang Kellerer DOCOMO Euro-Labs Landsberger Strasse 312 Munich Germany Email: kellerer@docomolab-euro.com Spiros Spirou Intracom Telecom 19.7 km Markopoulou Avenue 19002 Peania Greece Email: spis@intracom.com Dirk Staehle University of Wuerzburg Chair of Distributed Systems Am Hubland Wuerzburg 97074 Germany Email: dstaehle@informatik.uni-wuerzburg.de Maria Rodriguez Telefonica Investigacion y Desarrollo Emilio Vargas 6 28043 Madrid Spain Email: macr@tid.es Ioanna Papafili Athens University of Economics and Business Patission str. 76 10434 Athens Greece Email: iopapafi@aueb.gr Despotovic, et al. Expires January 6, 2010 [Page 18]