Network Working Group S. Kiesel, Ed. Internet-Draft NEC Intended status: Informational L. Popkin Expires: May 7, 2009 Pando Networks, Inc. S. Previdi Cisco Systems, Inc. R. Woundy Comcast Corporation Y R. Yang Yale University November 3, 2008 Application-Layer Traffic Optimization (ALTO) Requirements draft-kiesel-alto-reqs-01.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 May 7, 2009. Kiesel, et al. Expires May 7, 2009 [Page 1]
Internet-Draft ALTO Requirements November 2008 Abstract Many Internet applications are used to access resources, such as pieces of information or server processes, which are available in several equivalent replicas on different hosts. This includes, but is not limited to, peer-to-peer file sharing applications. The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications, which have to select one or several hosts from a set of candidates, that are able to provide 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 improve performance (or Quality of Experience) in the application while reducing 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 May 7, 2009 [Page 2]
Internet-Draft ALTO Requirements November 2008 Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. ALTO Terminology and Entities . . . . . . . . . . . . . . . . 6 4. ALTO Requirements . . . . . . . . . . . . . . . . . . . . . . 7 4.1. ALTO Interface . . . . . . . . . . . . . . . . . . . . . . 7 4.2. Error handling and overload protection for ALTO . . . . . 7 4.3. Security and Privacy . . . . . . . . . . . . . . . . . . . 9 5. Example rating criteria . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 14 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . . . 17 Kiesel, et al. Expires May 7, 2009 [Page 3]
Internet-Draft ALTO Requirements November 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 May 7, 2009 [Page 4]
Internet-Draft ALTO Requirements November 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 example, 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 network topology. As a result, they may choose their peers based on measurements and statistics which, in some situations, may 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 improve performance (or Quality of Experience) in the application while reducing 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 May 7, 2009 [Page 5]
Internet-Draft ALTO Requirements November 2008 3. ALTO Terminology and Entities This document uses the following ALTO-related terms, which are defined in [I-D.marocco-alto-problem-statement]: Application, Overlay Network, Peer, Resource, Resource Identifier, Resource Provider, Resource Consumer, Resource Directory, Transport Address, Host Location Attribute, ALTO Service, ALTO Server, ALTO Client, ALTO Query, ALTO Reply, ALTO Transaction, Local Traffic, Peering Traffic, Transit Traffic. Kiesel, et al. Expires May 7, 2009 [Page 6]
Internet-Draft ALTO Requirements November 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 information from the ALTO service, which provides guidance for selecting appropriate resource providers. REQ. 3: ALTO clients MUST be able to find out where to send ALTO queries. REQ. 4: One mode of ALTO operation is that ALTO clients may be embedded directly in the resource consumer (e.g., peer of an unstructured P2P application), which wants to access a resource. However, another mode of operation is to perform ALTO queries indirectly, via resource directories. These translate a resource identifier to a list of resource providers with their corresponding transport addresses. The resource directories may issue ALTO queries to solicit preference on such lists, considering the respective resource consumer. The ALTO protocol MUST support both modes of operation. One way to fulfill this requirement is to include in the ALTO query a a host location attribute of the resource consumer, i.e., the entity that will eventually perform the data transfer. REQ. 5: 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. 6: 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. 7: 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 Kiesel, et al. Expires May 7, 2009 [Page 7]
Internet-Draft ALTO Requirements November 2008 situation. REQ. 8: An overloaded ALTO server receiving too many requests MAY silently discard excess requests. REQ. 9: An ALTO client MAY retransmit an unanswered ALTO query after a reasonable amount of time, or it MAY query a different server. Otherwise, or if all retransmissions or queries to different servers have failed as well, the ALTO client MUST report to the application that no ALTO information is available. In this case, the application has to perform the resource provider selection without ALTO guidance. REQ. 10: 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. 11: 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 application that no ALTO information is available. In this case, the application has to perform the resource provider selection without ALTO guidance. REQ. 12: An ALTO server, which is operating close to its capacity limit, SHOULD be able to inform clients about its impending overload situation, even if it has not yet to discard excess query messages. An ALTO client receiving a reply message with this overload indication may use the message content for the intended purpose (i.e., guidance with respect to resource provider selection). However, with respect to overload control, it MUST behave as if it had not received a reply. REQ. 13: The ALTO protocol MAY have a mechanism by which the ALTO client can specify the required level of precision. If only a medium amount of data has to be exchanged, it may be sufficient to get a quick answer from the ALTO service, which results in a certain improvement compared to a resource provider selection without any ALTO guidance. 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 a recommendation that leads to higher improvements. REQ. 14: The ALTO protocol SHOULD support lifetime attributes, to enable caching of recommendations at ALTO clients. The ALTO protocol MAY specify an aging mechanism, which allows to give newer recommendations precedence over older ones. Kiesel, et al. Expires May 7, 2009 [Page 8]
Internet-Draft ALTO Requirements November 2008 4.3. Security and Privacy REQ. 15: The ALTO protocol 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. 16: Different instances of the ALTO service operated by different providers must be able to coexist. REQ. 17: The ALTO protocol MUST support mechanisms for mutual authentication and authorization of ALTO clients and servers. REQ. 18: 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. 19: The ALTO protocol MUST support different levels of detail in queries and responses, in order to protect the privacy of users, to ensure that the operators of ALTO servers and other users of the same application cannot derive sensitive information. REQ. 20: One ALTO interface SHOULD be defined in a way, that the operator of one ALTO server cannot easily deduce the resource identifier (e.g., file name in P2P file sharing) which the resource consumer seeking ALTO guidance wants to access. REQ. 21: If the ALTO protocol supports including privacy-sensitive information (such as resource identifiers or transport addresses) in the ALTO queries or replies, the protocol MUST also support encryption, in order to protect the privacy of users with respect to third parties. REQ. 22: The ALTO protocol MUST include appropriate mechanisms to protect the ALTO service against DoS attacks. Kiesel, et al. Expires May 7, 2009 [Page 9]
Internet-Draft ALTO Requirements November 2008 5. Example rating criteria The goal of ALTO is to provide guidance to resource consumers that have to select resource providers. The recommendations may be based on various rating criteria. The following list is not intended to be exhaustive, and it may later be moved to a separate document. o Topological distance between the resource consumer and the candidate resource provider, e.g., the number of traversed autonomous systems (AS), or whether the traffic will be local traffic, peering traffic, or transit traffic. o Expected cost for data exchange between the candidate resource provider and the resource consumer, according to the economic agreements between ISP. They may be expressed as absolute costs or relative costs, compared to retrieving the same data from another candidate resource provider. Rating criteria that SHOULD NOT be used by the ALTO service include: 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 May 7, 2009 [Page 10]
Internet-Draft ALTO Requirements November 2008 6. 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 May 7, 2009 [Page 11]
Internet-Draft ALTO Requirements November 2008 7. 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 May 7, 2009 [Page 12]
Internet-Draft ALTO Requirements November 2008 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 8.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-03 (work in progress), November 2008. Kiesel, et al. Expires May 7, 2009 [Page 13]
Internet-Draft ALTO Requirements November 2008 Appendix A. Contributors The authors were supported by the following people, who have contributed to this document: o Jason Livingood <Jason_Livingood@cable.comcast.com> o Saverio Niccolini <saverio.niccolini@nw.neclab.eu> o Jan Seedorf <jan.seedorf@nw.neclab.eu> o Martin Stiemerling <martin.stiemerling@nw.neclab.eu> Kiesel, et al. Expires May 7, 2009 [Page 14]
Internet-Draft ALTO Requirements November 2008 Appendix B. Acknowledgments The authors would like to thank o Vijay K. Gurbani <vkg@alcatel-lucent.com> o Enrico Marocco <enrico.marocco@telecomitalia.it> 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 May 7, 2009 [Page 15]
Internet-Draft ALTO Requirements November 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 May 7, 2009 [Page 16]
Internet-Draft ALTO Requirements November 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 May 7, 2009 [Page 17]