Network Working Group S. Kiesel, Ed. Internet-Draft NEC Intended status: Informational L. Popkin Expires: April 26, 2010 Pando Networks, Inc. S. Previdi Cisco Systems, Inc. R. Woundy Comcast Corporation Y R. Yang Yale University October 23, 2009 Application-Layer Traffic Optimization (ALTO) Requirements draft-ietf-alto-reqs-02.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 April 26, 2010. 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 publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights Kiesel, et al. Expires April 26, 2010 [Page 1] Internet-Draft ALTO Requirements October 2009 and restrictions with respect to this document. Kiesel, et al. Expires April 26, 2010 [Page 2] Internet-Draft ALTO Requirements October 2009 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. 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 performance (or Quality of Experience) in the application while reducing resource consumption in the underlying network infrastructure. This document enumerates requirements for ALTO, which should be considered when specifying, assessing, or comparing protocols and implementations, and it solicits feedback and discussion. Kiesel, et al. Expires April 26, 2010 [Page 3] Internet-Draft ALTO Requirements October 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology and architectural framework . . . . . . . . . . . 6 2.1. Requirements notation . . . . . . . . . . . . . . . . . . 6 2.2. ALTO terminology . . . . . . . . . . . . . . . . . . . . . 6 2.3. Architectural framework for ALTO . . . . . . . . . . . . . 7 2.4. Sample use cases . . . . . . . . . . . . . . . . . . . . . 7 3. ALTO requirements . . . . . . . . . . . . . . . . . . . . . . 10 3.1. ALTO client protocol . . . . . . . . . . . . . . . . . . . 10 3.1.1. General requirements . . . . . . . . . . . . . . . . . 10 3.1.2. Host group descriptor support . . . . . . . . . . . . 10 3.1.3. Rating criteria support . . . . . . . . . . . . . . . 11 3.1.4. Placement of entities and timing of transactions . . . 12 3.1.5. Protocol extensibility . . . . . . . . . . . . . . . . 13 3.1.6. Error handling and overload protection . . . . . . . . 14 3.2. ALTO server discovery . . . . . . . . . . . . . . . . . . 14 3.3. Security and privacy . . . . . . . . . . . . . . . . . . . 15 4. Host group descriptors . . . . . . . . . . . . . . . . . . . . 17 5. Rating criteria . . . . . . . . . . . . . . . . . . . . . . . 18 5.1. Distance-related rating criteria . . . . . . . . . . . . . 18 5.2. Charging-related rating criteria . . . . . . . . . . . . . 18 5.3. Performance-related rating criteria . . . . . . . . . . . 19 5.4. Inappropriate rating criteria . . . . . . . . . . . . . . 20 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 8.1. Normative References . . . . . . . . . . . . . . . . . . . 23 8.2. Informative References . . . . . . . . . . . . . . . . . . 23 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 24 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 Kiesel, et al. Expires April 26, 2010 [Page 4] Internet-Draft ALTO Requirements October 2009 1. Introduction The motivation for Application-Layer Traffic Optimization (ALTO) is described in the ALTO problem statement [I-D.ietf-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 "trackers" or "super peers" of a P2P application operated by the network provider, etc. Kiesel, et al. Expires April 26, 2010 [Page 5] Internet-Draft ALTO Requirements October 2009 2. Terminology and architectural framework 2.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]. 2.2. ALTO terminology This document uses the following ALTO-related terms, which are defined in [I-D.ietf-alto-problem-statement]: Application, Overlay Network, Application protocol, Peer, P2P, Resource, Resource Identifier, Resource Provider, Resource Consumer, Resource Directory, Transport Address, ALTO Service, ALTO Server, ALTO Client, ALTO Client Protocol, ALTO Query, ALTO Reply, ALTO Transaction, Provisioning protocol, Inter ALTO-Server Protocol, Local Traffic, Peering Traffic, Transit Traffic. Furthermore, the following additonal terms will be used: o Host Group Descriptor: Information used to describe the resouce consumer which seeks ALTO guidance, or one or several candidate resource providers. This can be, for example, a single IP address, an address prefix or address range that contains the host(s), or an autonomous system (AS) number. Different options may provide different levels of detail. Depending on the system architecture, this may have implications on the quality of the guidance ALTO is able to provide, on whether recommendations can be aggregated, and on how much privacy-sensitive information about users might be disclosed to additional parties. o Host Characteristics Attribute: Properties of a host (other than the host group descriptor), in particular related to its attachment to the network. This information may be stored in the ALTO server and transmitted in the ALTO protocol. It may be evaluated according to the rating criteria. o Rating Criterion: The condition or relation that defines the "better" in "better-than-random peer selection", which is the ultimate goal of ALTO. Examples may include "host's Internet access is not subject to volume based charging (flat rate)" or "low topological distance". Some rating criteria, such as "low topological distance", need to include a reference point, i. e., "low topological distance from a given resource consumer", which can be described by means of a host group descriptor. Kiesel, et al. Expires April 26, 2010 [Page 6] Internet-Draft ALTO Requirements October 2009 2.3. Architectural framework for ALTO There are various architectural options how ALTO could be implemented, and specifying or mandating one specific architecture is out of the scope of this document. The ALTO Working Group Charter [ALTO-charter] itemizes several key components, which shall be elaborated and specified by the ALTO Working Group. The ALTO problem statement [I-D.ietf-alto-problem-statement] defines a terminology (see Section 2.2) and presents a figure that gives a high-level overview of protocol interaction between ALTO elements. This document itemizes requirements for the following components of the abovementioned architecture: o The ALTO client protocol, which is used for sending ALTO queries and ALTO replies between ALTO client and ALTO server. o The discovery mechanism, which will be used by ALTO clients in order to find out where to send ALTO requests. o The overall architecture, especially with respect to security and privacy issues. Furthermore, this document describes the following data structures, which might be used in the ALTO client protocol: o Host group descriptors, which are used to describe the location of a host in the network topology. o Rating criteria, i. e., conditions that shall be evaluated in order to generate the ALTO guidance. Requirements regarding other components are not considered in the current version of this document, but may be added later. 2.4. Sample use cases The ALTO problem statement [I-D.ietf-alto-problem-statement] presents a figure that gives a high-level overview of protocol interaction between ALTO elements. The following figures are somewhat more elaborated and extended versions of it, in order to give some non- normative examples of ALTO usage. It can also be seen that, in some use cases, some of the requirements presented in later sections are more relevant than in others. Figure 1 shows an ALTO use case with a DHT-based P2P application. Kiesel, et al. Expires April 26, 2010 [Page 7] Internet-Draft ALTO Requirements October 2009 Using this distributed lookup mechanism, a peer can figure out which other peers are candidate resource providers for a desired resource. Every peer software includes an ALTO client, in order to request and receive guidance on peer selection from the ALTO servers. From an ALTO perspective this means that the ALTO servers will receive ALTO queries from a rather large number of different ALTO clients. The performance of many clients and their Internet connectivity may be rather limited and therefore, this puts certain restrictions on the amount of guiding data that can be sent to them. Furthermore, the privacy-sensitive IP addresses of the peers are visible to the (operators of the) ALTO servers, as these are also the source addresses of the ALTO query messages. Figure 2 shows an ALTO use case with a P2P application that makes use of a centralized resource directory (in some specific P2P implementations called a "tracker"). In this scenario the ALTO servers receive queries only from few entities, i.e., the resource directories. As these resource directories must be powerful machines anyway, it may be reasonable to send large amounts of ALTO guidance data to them, which will be cached there. Furthermore, in this scenario it may be possible to hide the exact addresses of the peers from the ALTO server. +-----+ =====| |** ==== +-----+ * ==== * * ==== * * +-----+ +------+===== +-----+ * | |.....| |======================| | * +-----+ +------+===== +-----+ * Source of ALTO ==== * * topological service ==== * * information ==== +-----+ * =====| |** +-----+ Legend: === ALTO client protocol *** Application protocol ... Provisioning protocol Figure 1: Overview of protocol interaction between ALTO elements, scenario without resource directory Kiesel, et al. Expires April 26, 2010 [Page 8] Internet-Draft ALTO Requirements October 2009 +-----+ **| |** ** +-----+ * ** * * ** * * +-----+ +------+ +-----+** +-----+ * | |.....| |=====| |**********| | * +-----+ +------+ +-----+** +-----+ * Source of ALTO Resource ** * * topological service directory ** * * information ("tracker") ** +-----+ * **| |** +-----+ Peers Legend: === ALTO client protocol *** Application protocol ... Provisioning protocol Figure 2: Overview of protocol interaction between ALTO elements, scenario with resource directory Kiesel, et al. Expires April 26, 2010 [Page 9] Internet-Draft ALTO Requirements October 2009 3. ALTO requirements 3.1. ALTO client protocol 3.1.1. General requirements REQ. ARv02-1: The ALTO service is provided by one or more ALTO servers. ALTO servers MUST implement the ALTO client protocol, for receiving ALTO queries from ALTO clients and for sending the corresponding ALTO replies. REQ. ARv02-2: ALTO clients MUST implement the ALTO client protocol, for sending ALTO queries to ALTO servers and for receiving the corresponding ALTO replies. REQ. ARv02-3: The format of the ALTO query message MUST allow the ALTO client to solicit guidance for selecting appropriate resource providers. REQ. ARv02-4: The format of the ALTO reply message MUST allow the ALTO server to express its guidance for selecting appropriate resource providers. REQ. ARv02-5: The detailed specification of a protocol is out of the scope of this document. However, any protocol specification that claims to implement the ALTO client protocol MUST be compliant to the requirements itemized in this document. 3.1.2. Host group descriptor support The ALTO guidance is based on the evaluation of several resource providers or groups of resource providers, which are characterized by means of host group descriptors, considering one or several rating criteria. REQ. ARv02-6: The ALTO client protocol MUST support the usage of several different host group descriptor types. REQ. ARv02-7: The ALTO client protocol specification MUST define a basic set of host group descriptor types, which MUST be supported by all implementations of the ALTO client protocol. REQ. ARv02-8: The ALTO client protocol MUST support the host group descriptor types "IPv4 address prefix" and "IPv6 address prefix." They can be used to specify the IP address of one host, or an IP address range (in CIDR notation), which contains all hosts in question. It is also possible to specify a broader address range (i.e., a shorter prefix length) than the intended group of hosts Kiesel, et al. Expires April 26, 2010 [Page 10] Internet-Draft ALTO Requirements October 2009 actually uses, in order to conceal their exact identity. REQ. ARv02-9: The ALTO client protocol specification MUST define an appropriate procedure for adding new host group descriptor types, e.g., by establishing an IANA registry. See Section 4 for a discussion of possible other host group descriptor types. REQ. ARv02-10: ALTO clients and ALTO servers MUST clearly identify the type of each host group descriptor sent in ALTO queries or replies. REQ. ARv02-11: For host group descriptor types other than "IPv4 address prefix" and "IPv6 address prefix", the host group descriptor type identification MUST be supplemented by a reference to a facility, which can be used to translate host group descriptors of that type to IPv4/IPv6 address prefixes, e.g., by means of a mapping table or an algorithm. REQ. ARv02-12: Protocol functions for mapping other host group descriptor types to IPv4/IPv6 address prefixes SHOULD be designed and specified as part of the ALTO client protocol, and the corresponding address mapping information SHOULD be made available by the same entity that wants to use these host group descriptors within the ALTO client protocol. However, an ALTO server or an ALTO client MAY also send a reference to an external mapping facility, e.g., a translation table to be downloaded as file via HTTP. REQ. ARv02-13: The ALTO client protocol specification MUST define mechanisms, which can be used by the ALTO client and the ALTO server to indicate that a host group descriptor used by the other party is of an unsupported type, or that the indicated mapping mechanism could not be used. 3.1.3. Rating criteria support REQ. ARv02-14: The ALTO client protocol MUST support the usage of several different rating criteria types. REQ. ARv02-15: The ALTO client protocol specification MUST define a basic set of rating criteria types, which MUST be supported by all implementations of the ALTO client protocol. REQ. ARv02-16: The ALTO client protocol specification MUST support the rating criteria type "relative operator's preference." This is a relative measure, i.e., it is not associtated with any unit of measurement. A higher rating according to this criterion indicates Kiesel, et al. Expires April 26, 2010 [Page 11] Internet-Draft ALTO Requirements October 2009 that the application should prefer the respective candidate resource provider over others with lower ratings (if no other reasons speak against it, such as transmission attempts suggesting that the path is currently congested). The operator of the ALTO server does not have to disclose how and based on which data the ratings are actually computed. Examples could be: cost for peering or transit traffic, traffic engineering inside the network, and other policies. REQ. ARv02-17: The ALTO client protocol specification MUST define an appropriate procedure for adding new rating criteria types, e.g., by establishing an IANA registry. See Section 5 for a discussion of possible other rating criteria. REQ. ARv02-18:The ALTO query message SHOULD allow the ALTO client to express which rating criteria should be considered, as well as their relative relevance for the specific application that will eventually make use of the guidance. REQ. ARv02-19:The ALTO reply message SHOULD allow the ALTO server to express which rating criteria have been considered when generating the reply. REQ. ARv02-20: The ALTO client protocol specification MUST define mechanisms, which can be used by the ALTO client and the ALTO server to indicate that a rating criteria used by the other party is of an unsupported type. 3.1.4. Placement of entities and timing of transactions With respect to the placement of ALTO clients, several modes of operation exist: o One mode of ALTO operation is that ALTO clients may be embedded directly in the resource consumer (e.g., peer of a DHT-based P2P application), which wants to access a resource. o Another mode of operation is to perform ALTO queries indirectly, via resource directories (e.g., tracker of a P2P application), which may issue ALTO queries to solicit preference on potential resource providers, considering the respective resource consumer. REQ. ARv02-21: The ALTO client protocol MUST support the mode of operation, in which the ALTO client is directly embedded in the resource consumer. REQ. ARv02-22: The ALTO client protocol MUST support the mode of operation, in which the ALTO client is embedded in the resource Kiesel, et al. Expires April 26, 2010 [Page 12] Internet-Draft ALTO Requirements October 2009 directory. REQ. ARv02-23: The ALTO client 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. ARv02-24: The ALTO client protocol MUST be designed in a way that different instances of the ALTO service operated by different providers can coexist. With respect to the timing of ALTO queries, several modes of operation exist: o In target-aware query mode, an ALTO client performs the ALTO query when the desired resource and a set of candidate resource providers are already known, i. e., after DHT lookups, queries to the resource directory, etc. o In target-independent query mode, ALTO queries are performed in advance or periodically, in order to receive comprehensive, "target-independent" guidance, which will be cached locally and evaluated later, when a resource is to be accessed. REQ. ARv02-25: The ALTO client protocol MUST support at least one of these two modes, either the target-aware or the target-independent query mode. REQ. ARv02-26: The ALTO client protocol SHOULD support both the target-aware and the target-independent query mode. REQ. ARv02-27: The ALTO client protocol SHOULD support lifetime attributes, to enable caching of recommendations at ALTO clients. REQ. ARv02-28: The ALTO client protocol SHOULD specify an aging mechanism, which allows to give newer recommendations precedence over older ones. REQ. ARv02-29: The ALTO client protocol MUST support scenarios with the ALTO client located in the private address realm behind a network address translator (NAT). There are different types of NAT, see [RFC4787] and [RFC5382]. 3.1.5. Protocol extensibility REQ. ARv02-30: The ALTO client protocol MUST include support for adding protocol extensions in a non-disruptive, backward-compatible way. Kiesel, et al. Expires April 26, 2010 [Page 13] Internet-Draft ALTO Requirements October 2009 REQ. ARv02-31: The ALTO client protocol MUST include protocol versioning support, in order to clearly distinguish between incompatible major versions of the protocol. 3.1.6. Error handling and overload protection REQ. ARv02-32: Any application designed to use ALTO MUST also work 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. ARv02-33: The ALTO client protocol MUST use TCP based transport. REQ. ARv02-34: An ALTO server, which is operating close to its capacity limit, MUST be able to inform clients about its impending overload situation, and require them to throttle their query rate. REQ. ARv02-35: An ALTO server, which is operating close to its capacity limit, MUST be able to inform clients about its impending overload situation, and redirect them to another ALTO server. REQ. ARv02-36: An ALTO server, which is operating close to its capacity limit, MUST be able to inform clients about its impending overload situation, and terminate the conversation with the ALTO client. REQ. ARv02-37: An ALTO server, which is operating close to its capacity limit, MUST be able to inform clients about its impending overload situation, and reject new conversation attempts. 3.2. ALTO server discovery The ALTO client protocol is supported by one or several ALTO server discovery mechanisms, which will be used by ALTO clients in order to find out where to send ALTO requests. REQ. ARv02-38: ALTO clients which are embedded in the resource consumer MUST be able to use the ALTO server discovery mechanism, in order to find one or several ALTO servers that can provide ALTO guidance suitable for the resource consumer. This mode of operation is called "resource consumer initiated ALTO server discovery". REQ. ARv02-39: ALTO clients which are embedded in a resource directory and perform third-party ALTO queries on behalf of a remote resource consumer MUST be able to use the ALTO server discovery mechanism, in order to find one or several ALTO servers that can provide ALTO guidance suitable for the respective resource consumer. Kiesel, et al. Expires April 26, 2010 [Page 14] Internet-Draft ALTO Requirements October 2009 This mode of operation is called "third-party ALTO server discovery". A classification and evaluation of architectural options for third- party ALTO server discovery can be found in [I-D.kiesel-alto-3pdisc]. REQ. ARv02-40: ALTO clients MUST be able to perform resource consumer initiated ALTO server discovery, even if they are located behind a network address translator (NAT). REQ. ARv02-41: ALTO clients MUST be able to perform third-party ALTO server discovery, even if they are located behind a network address translator (NAT). REQ. ARv02-42: ALTO clients MUST be able to perform third-party ALTO server discovery, even if the resource consumer, on behalf of which the ALTO query will be sent, is located behind a network address translator (NAT). REQ. ARv02-43: The ALTO server discovery mechanism may be specified and provided using an existing protocol or mechanism, such as DNS, DHCP, or PPP based automatic configuration, etc. These candidate "base protocols" differ with respect to their availability in various access network archtitectures and their suitability for third-party queries. When evaluating different options this should be taken into account, in order to limit the total number of ALTO server discovery mechanisms that have to be specified for supporting a reasonably wide range of deployment scenarios. REQ. ARv02-44: The ALTO server discovery mechanism SHOULD be able to return the respective contact information for several ALTO servers. REQ. ARv02-45: The ALTO server discovery mechanism SHOULD be able to indicate preferences for each returned ALTO server contact information. 3.3. Security and privacy REQ. ARv02-46: The ALTO client protocol MUST support mechanisms for the authentication of ALTO servers. REQ. ARv02-47: The ALTO client protocol MUST support mechanisms for the authentication of ALTO clients. REQ. ARv02-48: The ALTO client 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. ARv02-49: The ALTO client protocol MUST support different Kiesel, et al. Expires April 26, 2010 [Page 15] Internet-Draft ALTO Requirements October 2009 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. ARv02-50: The ALTO client protocol 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. ARv02-51: The ALTO client protocol MUST include appropriate mechanisms to protect the ALTO service against DoS attacks. Kiesel, et al. Expires April 26, 2010 [Page 16] Internet-Draft ALTO Requirements October 2009 4. Host group descriptors Host group descriptors are used in the ALTO client protocol to describe the location of a host in the network topology. The ALTO client protocol specification defines a basic set of host group descriptor types, which have to be suported by all implementations, and an extension procedure for adding new descriptor types (see Section 3.1.2). The following list gives an overview on further host group descriptor types that have been proposed in the past, or which are in use by by ALTO-related prototype implementations. This list is not intended as normative text. Instead, the only purpose of the following list is to document the descriptor types that have been proposed so far, and to solicit further feedback and discussion: o Autonomous System (AS) number o Protocol-specific group identifiers, which expand to a set of IP address ranges (CIDR) and/or AS numbers. In one specific solution proposal, these are called Partition ID (PID). Kiesel, et al. Expires April 26, 2010 [Page 17] Internet-Draft ALTO Requirements October 2009 5. Rating criteria Rating criteria are used in the ALTO client protocol to express topology- or connectivity-related properties, which are evaluated in order to generate the ALTO guidance. The ALTO client protocol specification defines a basic set of rating criteria, which have to be suported by all implementations, and an extension procedure for adding new criteria (see Section 3.1.3). The following list gives an overview on further rating criteria that have been proposed in the past, or which are in use by by ALTO-related prototype implementations. This list is not intended as normative text. Instead, the only purpose of the following list is to document the rating criteria that have been proposed so far, and to solicit further feedback and discussion: 5.1. Distance-related rating criteria o Relative topological distance: relative means that a larger numerical value means greater distance, but it is up to the ALTO service how to compute the values, and the ALTO client will not be informed about the nature of the information. One way of generating this kind of information MAY be counting AS hops, but when querying this parameter, the ALTO client MUST NOT assume that the numbers actually are AS hops. o Absolute topological distance, expressed in the number of traversed autonomous systems (AS). o Absolute topological distance, expressed in the number of router hops (i.e., how much the TTL value of an IP packet will be decreased during transit). o Absolute physical distance, based on knowledge of the approximate geolocation (continent, country) of an IP address. 5.2. Charging-related rating criteria o Traffic volume caps, in case the Internet access of the resource consumer is not charged by "flat rate". For each candidate resource provider, the ALTO service could indicate the amount of data that may be transferred from/to this resource provider until a given point in time, and how much of this amount has already been consumed. Furthermore, it would have to be indicated how excess traffic would be handled (e.g., blocked, throttled, or charged separately at an indicated price). The interaction of several applications running on a host, out of which some use this criterion while others don't, as well as the evaluation of this criterion in resource directories, which issue ALTO queries on Kiesel, et al. Expires April 26, 2010 [Page 18] Internet-Draft ALTO Requirements October 2009 behalf of other peers, are for further study. 5.3. Performance-related rating criteria The following rating criteria are subject to the remarks below. o The minimum achievable throughput between the resource consumer and the candidate resource provider, which is considered useful by the application (only in ALTO queries), or o An arbitrary upper bound for the throughput from/to the candidate resource provider (only in ALTO replies). This may be, but is not necessarily the provisioned access bandwidth of the candidate resource provider. o The maximum round-trip time (RTT) between resource consumer and the candidate resource provider, which is acceptable for the application for useful communication with the candidate resource provider (only in ALTO queries), or o An arbitrary lower bound for the RTT between resource consumer and the candidate resource provider (only in ALTO replies). This may be, for example, based on measurements of the propagation delay in a completely unloaded network. The ALTO client MUST be aware, that with high probability, the actual performance values differ significantly from these upper and lower bounds. In particular, an ALTO client MUST NOT consider the "upper bound for throughput" parameter as a permission to send data at the indicated rate without using congestion control mechanisms. The discrepancies are due to various reasons, including, but not limited to the facts that o the ALTO service is not an admission control system o the ALTO service may not know the instantaneous congestion status of the network o the ALTO service may not know all link bandwidths, i.e., where the bottleneck really is, and there may be shared bottlenecks o the ALTO service may not know whether the candidate peer itself is overloaded o the ALTO service may not know whether the candidate peer throttles the bandwidth it devotes for the considered application Kiesel, et al. Expires April 26, 2010 [Page 19] Internet-Draft ALTO Requirements October 2009 o the ALTO service may not know whether the candidate peer will throttle the data it sends to us (e.g., because of some fairness algorithm, such as tit-for-tat) Because of these inaccuracies and the lack of complete, instantaneous state information, which are inherent to the ALTO service, the application must use other mechanisms (such as passive measurements on actual data transmissions) to assess the currently achievable throughput, and it MUST use appropriate congestion control mechanisms in order to avoid a congestion collapse. Nevertheless, these rating criteria may provide a useful shortcut for quickly excluding candidate resource providers from such probing, if it is known in advance that connectivity is in any case worse than what is considered the minimum useful value by the respective application. 5.4. Inappropriate rating criteria Rating criteria that SHOULD NOT be defined for and used by the ALTO service include: o Performance metrics that are closely related to the instantaneous congestion status. The definition of alternate approaches for congestion control is explicitly out of the scope of ALTO. Instead, other appropriate means, such as using TCP based transport, have to be used to avoid congestion. Kiesel, et al. Expires April 26, 2010 [Page 20] Internet-Draft ALTO Requirements October 2009 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 April 26, 2010 [Page 21] Internet-Draft ALTO Requirements October 2009 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.ietf-alto-problem-statement]. For a set of specific security requirements please refer to Section 3.3 of this document. Kiesel, et al. Expires April 26, 2010 [Page 22] Internet-Draft ALTO Requirements October 2009 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 [ALTO-charter] Marocco, E. and V. Gurbani, "Application-Layer Traffic Optimization (ALTO) Working Group Charter", February 2009. [I-D.ietf-alto-problem-statement] Seedorf, J. and E. Burger, "Application-Layer Traffic Optimization (ALTO) Problem Statement", draft-ietf-alto-problem-statement-04 (work in progress), September 2009. [I-D.kiesel-alto-3pdisc] Kiesel, S. and M. Tomsu, "Third-party ALTO server discovery", draft-kiesel-alto-3pdisc-00 (work in progress), August 2009. [RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007. [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, RFC 5382, October 2008. Kiesel, et al. Expires April 26, 2010 [Page 23] Internet-Draft ALTO Requirements October 2009 Appendix A. Contributors The authors were supported by the following people, who have contributed to this document: o Zoran Despotovic o Jason Livingood o Saverio Niccolini o Jan Seedorf o Martin Stiemerling The authors would like to thank the members of the P2PI and ALTO mailing lists for their feedback. Kiesel, et al. Expires April 26, 2010 [Page 24] Internet-Draft ALTO Requirements October 2009 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 April 26, 2010 [Page 25] Internet-Draft ALTO Requirements October 2009 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 April 26, 2010 [Page 26]