Network Working Group S. Das Internet-Draft V. Narayanan Intended status: Standards Track Qualcomm, Inc. Expires: September 5, 2009 March 4, 2009 A Client to Service Query Response Protocol for ALTO draft-saumitra-alto-queryresponse-00 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 September 5, 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 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. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow Das & Narayanan Expires September 5, 2009 [Page 1] Internet-Draft multisource March 2009 modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Abstract ALTO aims to improve the peer selection in applications that have a choice to transfer data from multiple data resources. This draft presents a protocol for a flexible and extensible query response protocol between an ALTO aware client and ALTO service provider. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. ALTO Query Response Protocol . . . . . . . . . . . . . . . . . 4 3.1. ALTO Service Configuration . . . . . . . . . . . . . . . . 5 3.2. ALTO Service Discovery . . . . . . . . . . . . . . . . . . 7 3.3. ALTO Service Contact . . . . . . . . . . . . . . . . . . . 8 3.4. ALTO Message Formats . . . . . . . . . . . . . . . . . . . 8 3.4.1. Presentation Language . . . . . . . . . . . . . . . . 9 3.4.2. Common Header . . . . . . . . . . . . . . . . . . . . 9 3.4.3. Message Contents Format . . . . . . . . . . . . . . . 10 3.4.4. Response Codes and Response Errors . . . . . . . . . . 11 3.4.5. Location Context Query and Response . . . . . . . . . 12 3.4.6. Guidance Query and Response . . . . . . . . . . . . . 15 4. Example Use By An Application . . . . . . . . . . . . . . . . 18 5. Requirements Matching . . . . . . . . . . . . . . . . . . . . 19 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 9.1. Normative References . . . . . . . . . . . . . . . . . . . 22 9.2. Informative References . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 Das & Narayanan Expires September 5, 2009 [Page 2] Internet-Draft multisource March 2009 1. Introduction Internet traffic is dominated today by P2P (peer-to-peer) applications used for file transfer, voice communication and live streaming. Such an architecture for data transfer is attractive because it reduces the bandwidth costs of the content provider since they simply need to seed the content to a few nodes in the network which would then contribute upload bandwidth to assist the content provider's servers in the data transfer. Thus, the single point bottleneck at the content provider is eliminated and both users and content providers benefit. However such an approach is detrimental to the other important entity in the system: the ISPs. While p2p has led to the increased popularity of broadband connections and arguably increased subscribers for ISPs; it has also increased traffic costs for the ISPs. This is because P2P application's peer selection does not consider underlying network topology and link costs in that topology. Most p2p applications typically are only interested in improving their data transfer performance which is satisfied if the download link of the user is saturated. As shown in [10], traffic generated by popular P2P applications often cross network boundaries multiple times, overloading links which are frequently subject to congestion [11]. This happens because most p2p applications simply use random peer selection followed by monitoring and reevaluation. Even if p2p applications perform some network measurements, these typically tend to be round trip time estimation which may or may not lead to peer selection conducive to ISP interests. This led to ISPs efforts at shaping or blocking P2P traffic on specific ports. In response, p2p applictions started using dynamic ports to transfer data following whcih ISPs had to use deep packet protocol specific information to shape p2p flows. In response, p2p applications have started encrypting their connections. The use of TCP RST messages to deter costly p2p application data transfer has led to the network neutrality debate as well. It is in the ISPs interests to avoid the cat-and-mouse games of protocol-specific detection and mitigation while still not having to increase costs significantly to accomodate p2p traffic. One way to reduce the impact on ISPs would be the deployment of caching entities in the networks to reduce cross-ISP traffic and network distance of data transfer. However such an approach has several issues: (1) It is not clear who would deploy these high- bandwidth large-storage capable caches since it can be argued that caching pushes the costs from the content provider to the ISPs and. (2) The caches would need to be able to cache data from all p2p applications and consequently become complicated to deploy and Das & Narayanan Expires September 5, 2009 [Page 3] Internet-Draft multisource March 2009 maintain over time as p2p application evolve. This is specially difficult due to the heavy tailed nature of p2p content. (3) The use of caches opens up the issue of storage of illegal and copyrighted content. Thus, a solution is needed that can allow for peer selection by the p2p application themselves that is friendly to the ISPs network costs while being friendly to the application's objective of good performance for the user. Recent studies [12], [13], [14] have suggested that it may be possible to reduce the impact that P2P applications have on ISPs traffic costs. This is mainly achieved by informed peer selection in the P2P applications guided by network level metrics instead of random selection. However, p2p applications do not have a trust relationship with network operators and what may be good for the ISP is not necessarily good for the performance of the p2p applications. This creates a tension between these two competing interests and a solution for peer selection needs to address the interests of both the entities in the system. The ALTO working group aims to enable solutions that addresses this tension. It improves peer selection while being ISP friendly. The problem statement of ALTO is described in [1]. The current set of requirements is discussed in [2]. This document describes an ALTO client to service query response protocol optimizing traffic generated by P2P applications using information provided by third parties, i.e. the other peers in the network (through an aggregator ALTO service) or the network operator. The overall goal of optimizing the P2P application is for them to become more network-friendly, while at the same time allowing the networks to remain application-friendly. The client query response protocol is designed to be flexible and extensible for multiple aspects of the peer selection problem. such as FTP and HTTP replicas, locality aware neighbor selection in DHTs etc. It is also designed to be able to address peer selection that is ISP-centric as well as peer-centric. 2. Terminology 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 [3]. 3. ALTO Query Response Protocol The basic setting for the query response protocol is as follows: The ALTO ecosystem addressed by this draft includes an ALTO client that Das & Narayanan Expires September 5, 2009 [Page 4] Internet-Draft multisource March 2009 makes a query and an ALTO service running on an ALTO server that provides a response. Note that the ALTO client can make a query for itself or another client. In the remaining sections we discuss how to discover an ALTO service, communicate with an ALTO service; message formats for querying an ALTO service and for responding to an ALTO query The protocol operates over a single given interface at a time. The whole procedure can be repeated for a different interface. Each interface on a multihomed host may require the discovery of a different ALTO service (since the ISPs on each interface may be different). The peer selection is also dependent on the interface. Hence the protocol is meant to operate per interface. Any peer selection algorithms that work across interfaces would need to perform ALTO query reponse on each interface and use its own algorithm to decide which peer to connect to on which interface. OPEN ISSUE: detecting interfaces with Internet connectivity. 3.1. ALTO Service Configuration Some mechanisms for ALTO service discovery are described in this section. This specification defines a new content type "application/ p2p-alto+xml" for an MIME entity that contains alto information. An example document is shown below. Figure 1: ALTO Service Configuration Document The file MUST be a well formed XML document and it SHOULD contain an encoding declaration in the XML declaration. If the charset parameter of the MIME content type declaration is present and it is different from the encoding declaration, the charset parameter takes precedence. Every application conforment to this specification MUST accept the UTF-8 character encoding to ensure minimal interoperability. The namespace for the elements defined in this Das & Narayanan Expires September 5, 2009 [Page 5] Internet-Draft multisource March 2009 specification is urn:ietf:params:xml:ns:p2p:alto. The file can contain multiple "alto" elements where each one contains the configuration information for a different ALTO service. Each "alto" has the following attributes: o instance-name: name of the overlay o expiration: time in future at which this alto configuration is no longer valid and need to be retrieved again. This is expressed in seconds from the current time. o Inside each alto element, the following elements can occur: * alto-server This element contains the URI at which the ALTO server can be reached in a "uri" element. This URI is based on the syntax defined in [4]. More than one alto-server element may be present for load balance. The client can choose any one at random. The ALTO server may be running on a public IP address or be accessible via an overlay. * OPEN ISSUE: Make p2p URIs flexible enough to allow the ALTO service to be pointed to by an ip address and port number as well as a node id on an overlay. This enables an overlay based ALTO server as well as a more traditional model of a publicly available ALTO server. Draft [4] revisions will address this issue. * location-context This element represents (if set to true) that the ALTO service mandates a location context query (defined in Section Section 3.4.5) prior to a guidance query. * metric-supported This element represents a metric supported by the ALTO service. It has an attribute called "name" that represents the name of the metric such as latency, bandwidth, reliability). A set of metrics and their units should be standardized and MUST be understood by ALTO clients. More than one metric-supported element may be present. OPEN ISSUE: Which metrics should be standardized and what units should be used for referring to them as well as an accepted definition of what the units mean. Some important ones are listed below as a starting point. Applications MUST understand these basic set of metrics as well as typical values to use in queries. o name = "bandwidth", unit = "kbps" Das & Narayanan Expires September 5, 2009 [Page 6] Internet-Draft multisource March 2009 o name = "latency", unit = "msec", description = "A measure of the round trip time that is likely between client and a peer" o name = "pDistance", unit = "scalar" o name = "uptime", unit = "sec" o name = "loss", unit = "scalar" o name = "ASDistance", unit = "scalar" TODO: Sync these metrics with what is defined for p2psip diagnostics ([5] as well as the various proposals on ISP aided peer selection. For example having support for a metric such as pDistance would be useful for many different proposals on ISP aided peer selection. The metrics used in p2psip diagnostics may be metrics that are useful to aggregate at an ALTO service in an overlay. This service can then provide ALTO clients with peer selection guidance. 3.2. ALTO Service Discovery When a client first wishes to use an ALTO service, it starts with a discovery process to find a server for the ALTO service. The peer first determines the ALTO service name. This value is provided by the user or some other out of band provisioning mechanism. If the name is an IP address, that is directly used otherwise the peer MUST do a DNS SRV query using a Service name of "alto_discover" and a protocol of tcp to find an ALTO server. Once an address for the ALTO server is determined, the peer forms an HTTPS connection to that IP address. The certificate MUST match the overlay name as described in [6]. Whenever a peer contacts the ALTO server, it MUST fetch a new copy of the ALTO configuration file. To do this, the peer performs a GET to the URL formed by appending a path of "/alto/enroll" to the alto service URI. For example, if the ALTO service name was example.com, the URL would be "https://example.com/alto/enroll". The result is an XML configuration file described above, which replaces any previously learned configuration file for this ALTO service. OPEN ISSUE: performing ALTO service discovery in the context of a overlay (.e. using p2psip). This could be similar to the mechanisms presented for TURN server discovery in [7]. Das & Narayanan Expires September 5, 2009 [Page 7] Internet-Draft multisource March 2009 3.3. ALTO Service Contact ALTO client and server MUST use TLS for their communication. The ALTO client contacts the ALTO server using the URI in the ALTO configuration document. The following modes can be used for ALTO client-server communication Method 1: use a shared key between the ALTO client and ALTO server to set up the TLS session. Method 2: use server side authentication. Method 3: use TLS-PSK with an out of band provisioned password. This allows tiered guidance delivery to different clients. Using this method, ALTO servers can limit participation, provide QoS to different levels of users, and prevent misuse and overuse of the ALTO service TODO: Including service contact method information in the ALTO configuration document. 3.4. ALTO Message Formats The ALTO client to service protocol is a message-oriented request/ response protocol. The messages are encoded using binary fields. All integers are represented in network byte order. Each message has three parts, concatenated as shown below: +-------------------------+ | Common Header | +-------------------------+ | Message Contents | +-------------------------+ Figure 2: ALTO Packet The contents of these parts are as follows: o Common Header: Each message has a generic header. o Message Contents: The message being delivered between the client and the ALTO service. The following sections describe the format of each part of the message. Das & Narayanan Expires September 5, 2009 [Page 8] Internet-Draft multisource March 2009 3.4.1. Presentation Language The structures defined in this document are defined using a C-like syntax based on the presentation language used to define TLS. This notation is borrwed from the p2psip reload draft [7]. o All lengths are denoted in bytes, not objects. o Variable length values are denoted like arrays with angle brackets. o "select" is used to indicate variant structures. For instance, "uint16 array(0..2^8-2)" represents up to 254 bytes but only up to 127 values of two bytes (16 bits) each. An enum represents an enumerated type. The values associated with each possibility are represented in parentheses and the maximum value is represented as a nameless value, for purposes of describing the width of the containing integral type. For instance, Boolean represents a true or false: enum { false (0), true(1), (255)} Boolean; A boolean value is either a 1 or a 0 and is represented as a single byte on the wire. 3.4.2. Common Header struct { uint8 version; uint24 length; CommonOptions options[options_length]; } CommonHeader; Figure 3: ALTO Common Header The contents of the structure are: o version The version of the ALTO protocol being used. This document describes version 0.1, with a value of 0x01. o length The count in bytes of the size of the message, including the header. o options Contains a series of CommonOptions entries Das & Narayanan Expires September 5, 2009 [Page 9] Internet-Draft multisource March 2009 3.4.2.1. Common Header Options The common header can be extended with forwarding header options, which are a series of CommonOptions structures: enum { (255) } CommonOptionsType; struct { CommonOptionsType type; uint16 length; select (type) { /* Option values go here */ } option; } CommonOption; Figure 4: ALTO Common Header Options The contents of the structure are: o type The type of the option. o length The length of the rest of the structure. o option The option value 3.4.3. Message Contents Format struct { MessageCode message_code; opaque payload<0..2^24-1>; } MessageContents; Figure 5: ALTO Message Payload The contents of this structure are as follows: o message_code This indicates the message that is being sent. The code space is broken up as follows. * 0 Reserved * 1 .. 0x7fff Requests and responses. These code points are always paired, with requests being odd and the corresponding response being the request code plus 1. Thus, "location_query" (the query) has value 1 and "location_answer" (the response) has value 2 Das & Narayanan Expires September 5, 2009 [Page 10] Internet-Draft multisource March 2009 * 0xffff Error o message_body The message body itself, represented as a variable- length string of bytes. The bytes themselves are dependent on the code value. The next few sections describe the different ALTO methods used in the payload definition. 3.4.4. Response Codes and Response Errors An ALTO server processing a request returns its status in the message_code field. If the request was a success, then the message code is the response code that matches the request (i.e., the next code up). The response payload is then as defined in the request/ response descriptions. If the request failed, then the message code is set to 0xffff (error) and the payload MUST be an error_response PDU, as shown below. When the message code is 0xffff, the payload MUST be an ErrorResponse. struct { uint16 error_code; opaque error_info<0..2^16-1>; } ErrorResponse; Figure 6: ALTO Response Error The contents of this structure are as follows: o error_code A numeric error code indicating the error that occurred. o error_info A free form text string indicating the reason for the response for diagnostic purposes. The following error code values are defined. o Error_unauthorized: The client was not authorized to use the ALTO service. o Error_hla_not_found: The host location attribute (client location context) provided was invalid. o Error_overload: The ALTO service is currently overloaded with requests and cannot respond. Clients SHOULD implement an Das & Narayanan Expires September 5, 2009 [Page 11] Internet-Draft multisource March 2009 algorithm such as binary exponental backoff when restablishing contact with the ALTO service. o Error_option_not_found: An option header was not found. o Error_metric_not_found: A metric requested in the query was not understood by the ALTO service. o Error_no_matches: No peers matched the query. TODO: Make sure the list of errors are comprehensive. 3.4.5. Location Context Query and Response An ALTO service may need to set a location context for a client prior to the client sending a guidance query. ALTO services MUST choose whether to require a location context query or not in the ALTO configuration document. If the ALTO location-context filled in the configuration document is set to true, then a querying host MUST perform a location context query. 3.4.5.1. Location Context Query The location query message MUST contain a precision value specifying high precision (0x01), medium precision (0x02) or low precision (0x03). The ALTO service MAY choose to use this precision in determining a location context for the querying host. For example higher precision query would assign a more accurate location context to the querying host possibly consuming more resources in making that determination at the ALTO service. struct { uint8 precision; } LocationQuery; Figure 7: ALTO Query 3.4.5.2. Location Context Response A response to an ALTO location context query contains the HostLocationAtttribute of the querying host. This host location attribute identifies the querying host in the topology. It is flexible enough to allow an ALTO service to determine the parition id of a host in P4P and return it, determine the external IP address and return it etc. Das & Narayanan Expires September 5, 2009 [Page 12] Internet-Draft multisource March 2009 The host location attribute MUST be used in a guidance query. struct { HostLocationAttribute hla; } Response; Figure 8: ALTO Response The host location attribute is represented as shown below and can be either an ipv4 address, ipv6 address, overlay node identifer or partition identifier. This allows for referring to nodes in a flexible manner. For example, a host can perform an ALTO query to an overlay based ALTO service and refer to the peers to obtain guidance for, using node identifiers that make sense on the overlay. Das & Narayanan Expires September 5, 2009 [Page 13] Internet-Draft multisource March 2009 enum {reserved_addr(0), ipv4_address (1), ipv6_address (2), node_address (3), partition_id(4), (255)} HostLocationAttributeType; struct { uint32 addr; } IPv4Addr; struct { uint128 addr; } IPv6Addr; typedef opaque OverlayNodeAddr[16]; typedef opaque ISPPartitionAddr[16]; struct { AddressType type; uint8 length; select (type) { case ipv4_address: IPv4Addr v4addr; case ipv6_address: IPv6Addr v6addr; case node_address: OverlayNodeAddr nodeaddr; case partition: ISPPartitionAddr partitionaddr; /* This structure can be extended */ } HostLocationAttribute; Figure 9: Host Location Attribute Representation As shown in the Figure Figure 9, a host location attribute can encode ip addresses, node addresses or partition ids. OverlayNodeAddr and ISPPartitionAddr are fixed-length 128-bit structures represented as a series of bytes, most significant byte first. TODO: Make sure this is extensible enough to accomodate the needs to different ALTO proposals. Das & Narayanan Expires September 5, 2009 [Page 14] Internet-Draft multisource March 2009 3.4.5.3. Obtaining the external address on an interface If the ALTO location-context filled in the configuration document is set to false, a querying host MUST obtain the external address on the interface for which the host needs guidance using either of the two methods defined below. Method 1: The querying host SHOULD use the Session Traversal Utilities for NAT (STUN) [8] to determine a public IP address. If using this method, the host MUST the "Binding Request" message and the resulting "XOR-MAPPED-ADDRESS" parameter that is returned in the response. Using STUN requires cooperation from a publicly accessible STUN server. Thus, the host also requires configuration information that identifies the STUN server, or a domain name that can be used for STUN server discovery. To be selected for this purpose, the STUN server needs to provide the public reflexive transport address of the host. Method 2: The querying host may contact a predefined publicly accessible host configured to respond to a UDP packet on a predefined port; the data of the response could contain the source IP address that was in the request. Alternatively, a HTTP server at a particular URL could be configured to respond to a GET request with a "text/plain" body containing the IP address of the requester. However, transparent HTTP proxies can reduce the effectiveness of this method. 3.4.6. Guidance Query and Response Once a host location attribute is obtained either using external address discovery or a location context query, a guidance query can now be issued to the ALTO server. Das & Narayanan Expires September 5, 2009 [Page 15] Internet-Draft multisource March 2009 3.4.6.1. Guidance Query typedef opaque ObjectId[16]; struct{ uint8 metricname; uint8 operator; uint16 value; }MetricData; struct { ObjectId oid; HostLocationAttribute clienthla; uint8 precision; MetricData metrics<0..2^32-1> HostLocationAttribute destinations<0..2^32-1>; } Query; Figure 10: ALTO Guidance Query The ALTO guidance query is structured as follows: o clienthla: The host location attribute of the client. This need not be the same as the actual query host. This allows a third party to query on behalf on another host. This MUST be specified in the query. o precision: This defines the precision of ALTO guidance required by the client. Current this supports three values: 0x01 for high, 0x02 for medium, 0x03 for low. ALTO server MAY choose to use more complex or less complex guidance algorithms on the backend for different precisions requested. The ALTO client MUST define a value for this field. o metrics: This is a ranked list of constraints that denotes the interest of the client. Each metric constraint contains a metric, operator and value. The metricname is one of the standardized metric names supported by the specific ALTO service as defined in the ALTO configuration document. The operator field defines four values: 0x01 for less than, 0x02 for approximately equal to (within 10% of), 0x03 for greater than, 0x04 for NA. An operator of NA means that the querying host wants guidance on the metric but has no constraint on the metric value. Das & Narayanan Expires September 5, 2009 [Page 16] Internet-Draft multisource March 2009 o destinations: This is a list of peers the querying host wishes to select from. The destinations are a list of host location attributes. o oid: This is an optional field containing the object identifier the query host is aiming to transfer over the network. The querying host MAY choose to include this field and the ALTO server MAY choose to use it. This field allows ALTO services that manage object caches to include them in the guidance response by matching the oid. For example a querying host may only know 5 sources of an objects that are all interdomain sources of an object. If the oid is specified, the ALTO server could include network caches that match the query constraints in the list of peers returned to the querying host. OPEN ISSUE: can we have a widely accepted method of generating the oid which makes referencing objects and identifying additional peers with the object easier. One method to use for generating the oid is content-based naming where the oid is the cryptographic hash of the object data. Similar techniques have been proposed for data oriented data transfer recently (e.g. Data Oriented Transfer and Data Oriented Network Architecture) 3.4.6.2. Guidance Response The ALTO guidance response contains a ranked list of peers (resource owners) matching the query contrainsts. The query constraints MUST take preference in terms of their order in the query. Each item in the list MUST be the host location attribute of the peer, its associated metric and a lifetime value corresponding to the number of seconds this information is valid. This allows caching of peer selection guidance for repeated accesses to the same object by the client applications on the querying host. The ALTO service MAY choose to simply provide a ranking preserving the query constraints without revealing metric values. struct { HostLocationAttribute hla; MetricData metrics<0..2^8-1>; uint16 lifetime; } ResourceOwnerMetric; struct { ResourceOwnerMetric selection<0..2^32-1> } Response; Das & Narayanan Expires September 5, 2009 [Page 17] Internet-Draft multisource March 2009 Figure 11: ALTO Guidance Response 4. Example Use By An Application This section extends a use case and example proposed in [9] and shows how the use case fits this proposed protocol. Consider a BitTorrent client that wishes to use the ALTO information. The client will have a list of perhaps up to 200 initial candidate peers, out of which it will select perhaps 50 peers to try to connect to. In an initial implementation, the client could: Use the ALTO query protocol with metric of latency less than 50ms as the first metric constraint and pDistance NA as the second query constraint. This query can be sent out to the ALTO service and a response received which will contain all peers ranked in terms of their latency followed by their pDistance. Split the candidates into three sets: preferred (those with low latency and high pDistance values), to-be-avoided (those with low latency and low pDistance values), and default (high latency and high pDistance values) Select up to 25 candidates randomly from the preferred set. In particular, if there are fewer than 25 in the preferred set, select them all. Fill remaining slots up to 50 with candidates from the default set. If this didn't fill the slots (i.e., fewer than 50 of the candidates were in the union of preferred and default sets), fill the rest by candidates from the to-be-avoided set. When establishing connections after the initial startup, continue using the policy of giving up to half the slots to preferred with the rest for default and to-be-avoided only as last resort. When selecting a peer to optimistically unchoke, half the time select a preferred peer if there is one. (The particular numbers could be different.) If the preferred peers perform better than default ones, they will dominate the transfers. To-be-avoided peers are largely not contacted, unless the prohibitive policy is broad enough or the swarm is small enough that it is necessary to contact them to fill the slots. Das & Narayanan Expires September 5, 2009 [Page 18] Internet-Draft multisource March 2009 5. Requirements Matching This section outlines how the proposed protocol meets ALTO query response requirements. o REQ. 1: The ALTO service MUST implement one or several well- defined interfaces, which can be queried from ALTO clients. - This draft present one defined query response interface. o REQ. 2: The ALTO clients MUST be able to query information from the ALTO service, which provides guidance for selecting appropriate resource providers. - This draft allows the ALTO service to provide guidance on selecting resource providers. o REQ. 3: ALTO clients MUST be able to find out where to send ALTO queries - This draft defines some mechanisms for ALTO service discovery. o 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. - This draft does not mandate anything about the locations of ALTO clients and servers. The goal of the draft is to allow ALTO client and servers to be servers in the cloud, peers in an overlay or just IP endpoints. o REQ. 5: The syntax and semantics of the ALTO protocol MUST be extensible to allow the requirements of future applications to be adopted. - This draft attempts to make the query and response mechanisms generic to achieve this. o 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. - This draft specifies the use of TCP. o 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. - No requirement that ALTO be used or responses received in this draft. o REQ. 8: An overloaded ALTO server receiving too many requests MAY silently discard excess requests.- Server endpoint behavior is not included in this version of the draft. There is not requirement to respond. Das & Narayanan Expires September 5, 2009 [Page 19] Internet-Draft multisource March 2009 o REQ. 9: An ALTO client MAY retransmit an unanswered ALTO query after a reasonable amount of time, or it MAY query a different server. - Client endpoint behavior is not included in this version of the draft. o REQ. 10: An ALTO client MUST limit the total number of unanswered ALTO queries on a per-server basis. - Client endpoint behavior is not included in this version of the draft. o 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. - This is an implementation detail of the ALTO client. An error response exists to specify overload. o 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. - The overload error response achieves this purpose. o REQ. 13: The ALTO protocol MAY have a mechanism by which the ALTO client can specify the required level of precision. - This draft allows a coarse level of precision requested to be included in the query. The ALTO service MAY choose to use the precision. o REQ. 14: The ALTO protocol SHOULD support lifetime attributes, to enable caching of recommendations at ALTO clients.- This draft has support for lifetime attributes. o 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. - There is no requirement for the ALTO service to be tied to the querying host's ISP although they are likely to have the best information from a network impact point of view. o REQ. 16: Different instances of the ALTO service operated by different providers must be able to coexist. - Any ALTO service that can understand the query and provide an ALTO configuration document can provide an ALTO service. o REQ. 17: The ALTO protocol MUST support mechanisms for mutual authentication and authorization of ALTO clients and servers. - This draft specifies some mechanisms to achieve this. o REQ. 18: The ALTO protocol MUST support different levels of detail in queries and responses, in order for the operator of an ALTO Das & Narayanan Expires September 5, 2009 [Page 20] Internet-Draft multisource March 2009 service to be able to control how much information (e.g., about the network topology) is disclosed. - The ALTO service need only provide a ranking without specifying metrics in the guidance response it is chooses to. o 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. - This requirement is not very clearly defined. o 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. - The object id is an optional field in the query. If an ALTO service provider is deploying caches and p2p applications wish to gain from using them, they can optinally specify the object id. o 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. - This draft proposes using TLS to secure the channel between the client and server. o REQ. 22: The ALTO protocol MUST include appropriate mechanisms to protect the ALTO service against DoS attacks - This issue is still open. If clients cooperate with the overlay error response DoS should not be a threat. Generic DoS mitigation for an ALTO server is a much bigger problem and out of scope of this draft. 6. Security Considerations An entity could use the ALTO service to map out and ISPs preferences and potentially reverse engineer some information about its topology. This would require querying the ISP ALTO service from multiple vantage points. An ISP could limit queries made on behalf of other nodes from an entity to a smaller amount or slightly obfuscate/ randomize its responses to sometimes give higher metric values to peers in order to thwart such efforts. This initial draft does not look in detail at security considerations apart from that mentioned above. Future revisions will contain more details. Das & Narayanan Expires September 5, 2009 [Page 21] Internet-Draft multisource March 2009 7. IANA Considerations TODO. 8. Acknowledgments The author would like to thank Vidya Narayanan, Lakshminath Dondeti, Enrico Marocco, Vijay Gurbani, Jon Peterson for discussions that helped this draft. The draft was influenced by work being done in the P2PSIP WG. 9. References 9.1. Normative References [1] Seedorf, J. and E. Burger, "Application-Layer Traffic Optimization (ALTO) Problem Statement", draft-marocco-alto-problem-statement-04 (work in progress), February 2009. [2] Kiesel, S., Popkin, L., Previdi, S., Woundy, R., and Y. Yang, "Application-Layer Traffic Optimization (ALTO) Requirements", draft-kiesel-alto-reqs-01 (work in progress), November 2008. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [4] Hardie, T., "Mechanisms for use in pointing to overlay networks, nodes, or resources", draft-hardie-p2poverlay-pointers-00 (work in progress), January 2008. [5] Yongchao, S. and X. Jiang, "Diagnose P2PSIP Overlay Network", draft-ietf-p2psip-diagnostics-00 (work in progress), January 2009. [6] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [7] Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) Base Protocol", draft-ietf-p2psip-base-01 (work in progress), December 2008. [8] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for (NAT) (STUN)", draft-ietf-behave-rfc3489bis-18 (work in progress), July 2008. Das & Narayanan Expires September 5, 2009 [Page 22] Internet-Draft multisource March 2009 [9] Shalunov, S., Penno, R., and R. Woundy, "ALTO Information Export Service", draft-shalunov-alto-infoexport-00 (work in progress), October 2008. 9.2. Informative References [10] Karagiannis, T., Rodriguez, P., and K. Papagiannaki, "Should ISPs fear Peer-Assisted Content Distribution?", IMC Proceedings of the Internet Measurement Conference, 2005. [11] Akella, A., Seshan, S., and A. Shaikh, "An Empirical Evaluation of WideArea Internet Bottlenecks", Proceedings of ACM SIGCOMM, 2003. [12] Aggarwal, V., Feldmann, A., and C. Scheideler, "Can ISPs and P2P systems co-operate for improved performance?", ACM SIGCOMM Computer Communications Review (CCR), 37:3, pp. 29-40, 2006. [13] Xie, H., Krishnamurthy, A., Silberschatz, A., and R. Yang, "P4P: Explicit Communications for Cooperative Control Between P2P and Network Providers", Proceedings of ACM SIGCOMM, 2008. [14] Choffnes, D. and F. Bustamante, "Taming the Torrent: A practical approach to reducing cross-ISP traffic in P2P systems", Proceedings of ACM SIGCOMM, 2008. [15] Madhyastha, H., Isdal, T., Piatek, M., Dixon, C., Anderson, T., Krishnamurthy, A., and A. Venkataramani, "iPlane: an information plane for distributed services", Proceedings of USENIX OSDI, 2006. Authors' Addresses Saumitra M. Das Qualcomm, Inc. 3195 Kifer Road Santa Clara, CA USA Phone: +1 408-533-9529 Email: saumitra@qualcomm.com Das & Narayanan Expires September 5, 2009 [Page 23] Internet-Draft multisource March 2009 Vidya Narayanan Qualcomm, Inc. 5775 Morehouse Dr San Deigo, CA USA Phone: +1 858-845-2483 Email: vidyan@qualcomm.com Das & Narayanan Expires September 5, 2009 [Page 24]