Network Working Group S. Kiesel, Ed. Internet-Draft NEC Intended status: Informational L. Popkin Expires: January 5, 2009 Pando Networks, Inc. S. Previdi Cisco Systems, Inc. R. Woundy Comcast Corporation Y R. Yang Yale University July 4, 2008 Application-Layer Traffic Optimization (ALTO) Requirements draft-kiesel-alto-reqs-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 5, 2009. Kiesel, et al. Expires January 5, 2009 [Page 1] Internet-Draft ALTO Requirements July 2008 Abstract Many Internet applications are used to access resources, such as server processes or pieces of information, which are available in several equivalent replicas on different hosts. This includes, but is not limited to, peer-to-peer filesharing applications. The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications, which have to select one host out of several candidates for providing a desired resource. These recommendations 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 optimize performance (or Quality of Experience) in the application while minimizing resource consumption in the underlying network infrastructure. This document enumerates an initial set of requirements for ALTO and solicits feedback and discussion. Kiesel, et al. Expires January 5, 2009 [Page 2] Internet-Draft ALTO Requirements July 2008 Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. ALTO Terminology and Entities . . . . . . . . . . . . . . . . 6 4. ALTO Requirements . . . . . . . . . . . . . . . . . . . . . . 8 4.1. ALTO Interface . . . . . . . . . . . . . . . . . . . . . . 8 4.2. Error handling and overload protection for ALTO . . . . . 9 4.3. Security and Privacy . . . . . . . . . . . . . . . . . . . 10 5. Example rating criteria . . . . . . . . . . . . . . . . . . . 12 6. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 9.2. Informative References . . . . . . . . . . . . . . . . . . 16 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 17 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . . . 20 Kiesel, et al. Expires January 5, 2009 [Page 3] Internet-Draft ALTO Requirements July 2008 1. Requirements notation 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 [RFC2119]. Kiesel, et al. Expires January 5, 2009 [Page 4] Internet-Draft ALTO Requirements July 2008 2. Introduction The motivation for Application-Layer Traffic Optimization (ALTO) is described in the ALTO problem statement: "A significant part of the Internet traffic today is generated by peer-to-peer applications used for file sharing, realtime communications and live media streaming. Such applications often deal with large amounts of data in direct peer-to-peer connections, but they usually have little knowledge of the underlying topology, both at the overlay layer and the network layer. As a result, they may choose their peers based on measurements and statistics which, in some specific situations, often lead to suboptimal choices." [I-D.marocco-alto-problem-statement]. The goal of ALTO is to provide information which can help peer-to- peer (P2P) applications to make better decisions with respect to peer selection. However, ALTO may be useful for non-P2P applications as well. For example, clients of client-server applications may use information provided by ALTO to select one of several servers or information replicas. As another example, ALTO information could be used to select a media relay needed for NAT traversal. The goal of these informed decisions is to optimize performance (or Quality of Experience) in the application while minimizing resource consumption in the underlying network infrastructure. Usually, it would be difficult or even impossible for application entities to acquire this information by other mechanisms (e.g., using measurements between the peers of a P2P overlay), because of complexity or because it is based on network topology information, network operational costs, or network policies, which the respective network provider does not want to disclose in detail. The logical entities that provide the ALTO service do not take part in the actual user data transport, i.e., they do not implement functions for relaying user data. They may be placed on various kinds of physical nodes, e.g., on dedicated servers, as auxiliary processes in routers, on "super peers" of a P2P application operated by the network provider, etc. Kiesel, et al. Expires January 5, 2009 [Page 5] Internet-Draft ALTO Requirements July 2008 3. ALTO Terminology and Entities This document uses the following terms related to ALTO. o Client Application: An application (e.g., P2P filesharing) that uses the ALTO service to optimize its performance (or Quality of Experience) while minimizing resource consumption in the underlying network infrastructure. o Client Application Resource: A resource, such as a server process or a piece of information, which can be accessed using the Client Application. It is assumed that this resource is available in several equivalent replicas on different Client Application Providers. o Client Application Resource Identifier: An application layer identifier used to identify a Client Application Resource, no matter how many replicas thereof exist. o Client Application Provider: A specific entity of the Client Application (e.g., one node of a P2P overlay), which provides a specific Client Application Resource. The mechanisms used to spread the information that a specific Client Application entity is able and willing to act as Client Application Provider for a specific Client Application Resource are out of the scope of ALTO. o Client Application Consumer: A specific entity of the Client Application (e.g., one node of a P2P overlay), which wants to access a Client Application Resource, and therefore seeks guidance from ALTO to select a good Client Application Provider. The Client Application Consumer will eventually initiate the transfer of user data. o Transport Address: The lower layer address information needed to initiate data transfer from a specific Client Application Provider. This might be just an IP address. It might also be augmented by, e.g., specifying the transport protocol and the port number. o Client Application Directory: An entity which is separate from the Client Application Consumer, and which assists the Client Application Consumer to translate a Client Application Resource Identifier into a set of Transport Addresses, e.g., a P2P tracker. Some Client Applications do not use this concept and do the address mapping directly in the Client Application Consumer. o Host Location Attribute: Information which is related to the location of a host in the network topology. The ALTO service Kiesel, et al. Expires January 5, 2009 [Page 6] Internet-Draft ALTO Requirements July 2008 gives recommendations based on this information. A host location attribute may consist, for example, of an IP address, an address prefix or address range that contains the host, an autonomous system (AS) number, or any other localization attribute. These different options may provide different levels of detail. This has implications on the quality of the recommendations ALTO is able to provide, on whether recommendations can be aggregated, and on how much privacy-sensitive information about users is disclosed to the ALTO servers. o ALTO service: If several Client Application Providers are able to provide the same Client Application Resource the ALTO service gives guidance to a Client Application Consumer, on which Client Application Provider to select, in order to optimize its performance (or Quality of Experience) while minimizing resource consumption in the underlying network infrastructure. o ALTO server: A logical entity that provides interfaces, which can be used to query the ALTO service. o ALTO client: The logical ALTO protocol entity that sends ALTO queries. Depending on the architecture of the Client Application it may be embedded in the Client Application Consumer or in the Client Application Directory. Kiesel, et al. Expires January 5, 2009 [Page 7] Internet-Draft ALTO Requirements July 2008 4. ALTO Requirements 4.1. ALTO Interface REQ. 1: The ALTO service MUST implement one or several well-defined interfaces, which can be queried from ALTO clients. REQ. 2: The ALTO clients MUST be able to query ALTO information from the ALTO service, which is related to network topology or other network properties. REQ. 3: ALTO clients may be embedded directly in the Client Application Consumer (e.g., peer of an unstructured P2P application), which wants to access a Client Application Resource. However, ALTO queries may also be performed indirectly, via Client Application Directories, such as name servers, directory servers, trackers, etc., which translate a Client Application Resource Identifier to a list of Transport Addresses. They may use ALTO to return the "best" addresses to the actual Client Application Consumer. The ALTO protocol MUST support both modes of operation. REQ. 4: ALTO Clients MUST be able to find out where to send ALTO queries. REQ. 5: The ALTO service MUST implement a query/response protocol. An ALTO transaction consists of a query request from an ALTO client to the ALTO service, and a corresponding reply. The request MUST contain a Host Location Attribute of the Client Application Consumer, i.e., the entity that will actually perform the data transfer from the desired Client Application Resource. It is assumed that this resource, such as a server process or a piece of information, is available in several equivalent replicas on different hosts. In the request, the ALTO client MAY present a list of Transport Addresses or Host Location Attributes of hosts, which are known to be able to provide the desired resource. Alternatively, it MAY present a Client Application Resource Identifier to indicate the resource it wants to access. In the latter case a mechanism, which is specific to the Client Application, is required first, to determine Transport Addresses of candidate Client Application Providers. The ALTO service rates these alternatives according to various criteria, such as the examples given in Section 5. The reply MAY contain a list of Transport Addresses or Host Location Attributes, which is sorted according to these criteria. Alternatively or additionally, the reply MAY contain quantifiable or Kiesel, et al. Expires January 5, 2009 [Page 8] Internet-Draft ALTO Requirements July 2008 non-quantifiable information about every possible Client Application Provider, so that the ALTO client can perform the rating and decision itself. REQ. 6: The syntax and semantics of the ALTO protocol MUST be extensible to allow the requirements of future applications to be adopted. This includes, amongst others, support for adding protocol extensions in a non-disruptive, backward-compatible way, as well as protocol versioning support to clearly distinguish between incompatible major versions of the protocol. REQ. 7: The information available from the ALTO service is not a replacement for congestion control mechanisms. Applications using ALTO MUST ensure that they do not cause congestion in the network, e.g., by using TCP transport, which includes congestion control mechanisms. 4.2. Error handling and overload protection for ALTO REQ. 8: Any application designed to use ALTO MUST also work reasonably if no ALTO servers can be found or if no responses to ALTO queries are received, e.g., due to connectivity problems or overload situation. REQ. 9: An overloaded ALTO server receiving too many requests MAY silently discard excess requests. REQ. 10: An ALTO client MAY retransmit an unanswered ALTO query after a reasonable time, or it MAY query a different server. Otherwise it MUST report to the Client Application that it has to make its decision without ALTO support. REQ. 11: An ALTO client MUST limit the total number of unanswered ALTO queries on a per-server basis. This limit MUST be reduced if a request times out and MAY be increased if several subsequent queries succeed without a timeout. REQ. 12: If an ALTO query cannot be sent because the maximum number of outstanding queries is reached, the ALTO client MAY wait for some time. Then, if it is still not possible to send the query, it MUST report to the Client Application that it has to make its decision without ALTO support. REQ. 13: The ALTO protocol MUST have a server overload flag in the reply messages. If an ALTO server is operating close to its capacity limit it MAY set this flag in responses, even if it has not yet to discard excess query messages. An ALTO client receiving a reply with the server overload flag set can use the reply for the intended Kiesel, et al. Expires January 5, 2009 [Page 9] Internet-Draft ALTO Requirements July 2008 purpose (e.g., peer selection). However, with respect to overload control, it MUST behave as if it had not received a reply. REQ. 14: The ALTO protocol MAY have a mechanism by which the client can specify the required level of precision. If only a medium amount of data has to be retrieved, a quick answer from the ALTO server with a good but not necessarily optimal peer recommendation may be sufficient. If, however, very large amounts of data will be transferred or the association will persist for an extended time, the client might request the ALTO service to spend more resources to make an optimal recommendation. REQ. 15: In the request, a client SHOULD be able to indicate how many different recommended Host Location Attributes or Transport Addresses of Client Application Providers it wants to receive. An ALTO server SHOULD NOT send more than this number of recommended locations. An ALTO server MAY send fewer than this number of recommended locations. REQ. 16: The ALTO protocol SHOULD support lifetime attributes, to enable caching of recommendations at ALTO clients. 4.3. Security and Privacy REQ. 17: The ALTO protocols must be designed in a way that the ALTO service can be provided by an operator which is not the operator of the IP access network REQ. 18: Different instances of the ALTO service operated by different providers must be able to coexist. REQ. 19: The ALTO protocol MUST support mechanisms for mutual authentication and authorization of ALTO clients and servers. REQ. 20: The ALTO protocol MUST support different levels of detail in queries and responses, in order for the operator of an ALTO service to be able to control how much information (e.g., about the network topology) is disclosed. REQ. 21: The ALTO protocol MUST support different levels of detail in queries and responses, in order to protect the privacy of users, so that the operators of ALTO servers and other users of the same Client Application cannot derive sensitive information. REQ. 22: One ALTO interface should be defined in a way, that the operator of one ALTO server cannot easily deduce the resource (e.g., filename in P2P filesharing) which the requester wants to obtain. REQ. 23: The ALTO protocol MUST support encryption, in order to Kiesel, et al. Expires January 5, 2009 [Page 10] Internet-Draft ALTO Requirements July 2008 protect the privacy of users with respect to third parties. REQ. 24: The ALTO protocol must be designed in a way that the ALTO service is protected against DoS attacks. Kiesel, et al. Expires January 5, 2009 [Page 11] Internet-Draft ALTO Requirements July 2008 5. Example rating criteria Alternative resources for servers or data replicas may be rated according to the following criteria. This list is not exhaustive, and may later be moved to a separate document. o topological distance, e.g., AS hop count, or whether peer is reachable via own network / revenue-neutral peering / global upstream o expected cost for data transport Criteria that SHOULD NOT be used for rating o Performance metrics related to instantaneous congestion status. This has to be probed and adapted to continuously, e.g., using TCP. Kiesel, et al. Expires January 5, 2009 [Page 12] Internet-Draft ALTO Requirements July 2008 6. Open Issues Is ALTO completely unaware of content, e.g., P2P filesharing file names? ALTO could be combined with trackers. As an alternative, trackers can ask an ALTO-backend. Do we consider both cases? Kiesel, et al. Expires January 5, 2009 [Page 13] Internet-Draft ALTO Requirements July 2008 7. IANA Considerations This requirements document does not mandate any immediate IANA actions. However, such IANA considerations may arise from future ALTO specification documents which try to meet the requirements given here. Kiesel, et al. Expires January 5, 2009 [Page 14] Internet-Draft ALTO Requirements July 2008 8. Security Considerations High-level security considerations for the ALTO service can be found in the "Security Considerations" section of the ALTO problem statement [I-D.marocco-alto-problem-statement]. For a set of specific security requirements please refer to Section 4.3 of this document. Kiesel, et al. Expires January 5, 2009 [Page 15] Internet-Draft ALTO Requirements July 2008 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. 9.2. Informative References [I-D.marocco-alto-problem-statement] Marocco, E. and V. Gurbani, "Application-Layer Traffic Optimization (ALTO) Problem Statement", draft-marocco-alto-problem-statement-00 (work in progress), April 2008. Kiesel, et al. Expires January 5, 2009 [Page 16] Internet-Draft ALTO Requirements July 2008 Appendix A. Contributors The authors were supported by the following people, who have contributed to this document: o Jason Livingood o Saverio Niccolini o Jan Seedorf o Martin Stiemerling Kiesel, et al. Expires January 5, 2009 [Page 17] Internet-Draft ALTO Requirements July 2008 Appendix B. Acknowledgments The authors would like to thank o Vijay K. Gurbani o Enrico Marocco for fostering discussions that lead to the creation of this document, and for giving valuable comments on it. Sebastian Kiesel, Saverio Niccolini, Jan Seedorf, and Martin Stiemerling are partially supported by the NAPA-WINE project (Network-Aware P2P-TV Application over Wise Networks, http://www.napa-wine.org), a research project supported by the European Commission under its 7th Framework Program (contract no. 214412). 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 NAPA-WINE project or the European Commission. Laird Popkin and Y. Richard Yang are grateful to the many contributions made by the members of the P4P working group and Yale Laboratory of Networked Systems. The P4P working group is hosted by DCIA. Kiesel, et al. Expires January 5, 2009 [Page 18] Internet-Draft ALTO Requirements July 2008 Authors' Addresses Sebastian Kiesel (editor) NEC Europe Ltd., Network Laboratories Europe Kurfuersten-Anlage 36 Heidelberg 69115 Germany Phone: +49 6221 4342 232 Email: sebastian.kiesel@nw.neclab.eu Laird Popkin Pando Networks, Inc. Email: laird@pando.com Stefano Previdi Cisco Systems, Inc. Email: sprevidi@cisco.com Richard Woundy Comcast Corporation Email: Richard_Woundy@cable.comcast.com Yang Richard Yang Yale University Email: yry@cs.yale.edu Kiesel, et al. Expires January 5, 2009 [Page 19] Internet-Draft ALTO Requirements July 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Kiesel, et al. Expires January 5, 2009 [Page 20]