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

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   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 (
   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.


   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",
   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

   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.

   <?xml version="1.0" encoding="UTF-8"?>
        <alto instance-name="" expiration="86400">
          <alto-server uri=""/>
          <location-context value="false"/>
          <metric-supported name="latency"/>
          <metric-supported name="pDistance"/>
          <metric-supported name="bandwidth"/>

               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

      *  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,
   the URL would be "".  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

   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

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

   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  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

   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

   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

   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.  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  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

   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  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

   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  Guidance Query

   typedef opaque ObjectId[16];

      uint8 metricname;
      uint8 operator;
      uint16 value;

   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

   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)  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

   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

   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

Das & Narayanan         Expires September 5, 2009              [Page 21]

Internet-Draft                 multisource                    March 2009

7.  IANA Considerations


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,

   [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

   Phone: +1 408-533-9529

Das & Narayanan         Expires September 5, 2009              [Page 23]

Internet-Draft                 multisource                    March 2009

   Vidya Narayanan
   Qualcomm, Inc.
   5775 Morehouse Dr
   San Deigo, CA

   Phone: +1 858-845-2483

Das & Narayanan         Expires September 5, 2009              [Page 24]