[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 draft-ietf-alto-reqs

Network Working Group                                     S. Kiesel, Ed.
Internet-Draft                                                       NEC
Intended status: Informational                                 L. Popkin
Expires: September 10, 2009                         Pando Networks, Inc.
                                                              S. Previdi
                                                     Cisco Systems, Inc.
                                                               R. Woundy
                                                     Comcast Corporation
                                                               Y R. Yang
                                                         Yale University
                                                           March 9, 2009


       Application-Layer Traffic Optimization (ALTO) Requirements
                     draft-kiesel-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.  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 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.

   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 10, 2009.



Kiesel, et al.         Expires September 10, 2009               [Page 1]

Internet-Draft              ALTO Requirements                 March 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.









































Kiesel, et al.         Expires September 10, 2009               [Page 2]

Internet-Draft              ALTO Requirements                 March 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 September 10, 2009               [Page 3]

Internet-Draft              ALTO Requirements                 March 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 . . . . . . . . . . . . .  6
     2.4.  Sample use cases . . . . . . . . . . . . . . . . . . . . .  7
   3.  ALTO requirements  . . . . . . . . . . . . . . . . . . . . . .  9
     3.1.  ALTO client protocol . . . . . . . . . . . . . . . . . . .  9
       3.1.1.  General requirements . . . . . . . . . . . . . . . . .  9
       3.1.2.  Protocol semantics . . . . . . . . . . . . . . . . . .  9
       3.1.3.  Error handling and overload protection . . . . . . . . 11
     3.2.  ALTO server discovery  . . . . . . . . . . . . . . . . . . 11
     3.3.  Security and privacy . . . . . . . . . . . . . . . . . . . 12
   4.  Host location attributes . . . . . . . . . . . . . . . . . . . 13
   5.  Rating criteria  . . . . . . . . . . . . . . . . . . . . . . . 14
     5.1.  Distance-related rating criteria . . . . . . . . . . . . . 14
     5.2.  Charging-related rating criteria . . . . . . . . . . . . . 15
     5.3.  Performance-related rating criteria  . . . . . . . . . . . 15
     5.4.  Inappropriate rating criteria  . . . . . . . . . . . . . . 16
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 17
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 18
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 19
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 19
   Appendix A.  Contributors  . . . . . . . . . . . . . . . . . . . . 20
   Appendix B.  Acknowledgments . . . . . . . . . . . . . . . . . . . 21
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22






















Kiesel, et al.         Expires September 10, 2009               [Page 4]

Internet-Draft              ALTO Requirements                 March 2009


1.  Introduction

   The motivation for Application-Layer Traffic Optimization (ALTO) is
   described in the ALTO problem statement:

   "Peer-to-peer applications, such as file sharing, real-time
   communication, and live media streaming, use a significant amount of
   Internet resources.  Such applications often transfer large amounts
   of data in direct peer-to-peer connections.  However, they usually
   have little knowledge of the underlying network topology.  As a
   result, they may choose their peers based on measurements and
   statistics that, in many situations, may lead to suboptimal choices."
   [I-D.marocco-alto-problem-statement].

   The goal of ALTO is to provide information which can help peer-to-
   peer (P2P) applications to make better decisions with respect to peer
   selection.  However, ALTO may be useful for non-P2P applications as
   well.  For example, clients of client-server applications may use
   information provided by ALTO to select one of several servers or
   information replicas.  As another example, ALTO information could be
   used to select a media relay needed for NAT traversal.  The goal of
   these informed decisions is to improve performance (or Quality of
   Experience) in the application while reducing resource consumption in
   the underlying network infrastructure.

   Usually, it would be difficult or even impossible for application
   entities to acquire this information by other mechanisms (e.g., using
   measurements between the peers of a P2P overlay), because of
   complexity or because it is based on network topology information,
   network operational costs, or network policies, which the respective
   network provider does not want to disclose in detail.

   The logical entities that provide the ALTO service do not take part
   in the actual user data transport, i.e., they do not implement
   functions for relaying user data.  They may be placed on various
   kinds of physical nodes, e.g., on dedicated servers, as auxiliary
   processes in routers, on "trackers" or "super peers" of a P2P
   application operated by the network provider, etc.













Kiesel, et al.         Expires September 10, 2009               [Page 5]

Internet-Draft              ALTO Requirements                 March 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.marocco-alto-problem-statement]:

   Application, Overlay Network, Application protocol, Peer, P2P,
   Resource, Resource Identifier, Resource Provider, Resource Consumer,
   Resource Directory, Transport Address, Host Location Attribute, 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.

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




Kiesel, et al.         Expires September 10, 2009               [Page 6]

Internet-Draft              ALTO Requirements                 March 2009


   o  Host location attributes, which are used to describe the location
      of a host in the network topology.

   o  Rating criteria, i. e., properties 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.marocco-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.
   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.








Kiesel, et al.         Expires September 10, 2009               [Page 7]

Internet-Draft              ALTO Requirements                 March 2009


                                               +-----+
                                          =====|     |**
                                      ====     +-----+  *
                                  ====            *     *
                              ====                *     *
     +-----+     +------+=====                 +-----+  *
     |     |.....|      |======================|     |  *
     +-----+     +------+=====                 +-----+  *
   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


                                               +-----+
                                             **|     |**
                                           **  +-----+  *
                                         **       *     *
                                       **         *     *
     +-----+     +------+     +-----+**        +-----+  *
     |     |.....|      |=====|     |**********|     |  *
     +-----+     +------+     +-----+**        +-----+  *
   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 September 10, 2009               [Page 8]

Internet-Draft              ALTO Requirements                 March 2009


3.  ALTO requirements

3.1.  ALTO client protocol

3.1.1.  General requirements

   REQ.  RQv02-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.  RQv02-2: ALTO clients MUST implement the ALTO client protocol,
   for sending ALTO queries to ALTO servers and for receiving the
   corresponding ALTO replies.

   REQ.  RQv02-3: 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.  Protocol semantics

   REQ.  RQv02-4: The format of the ALTO query message MUST allow the
   ALTO client to solicit guidance for selecting appropriate resource
   providers.

   REQ.  RQv02-5: The ALTO guidance is be based on the evaluation of one
   or several rating criteria (see Section 5).  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.  RQv02-6: The format of the ALTO reply message MUST allow the
   ALTO server to express his guidance for selecting appropriate
   resource providers.

   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.




Kiesel, et al.         Expires September 10, 2009               [Page 9]

Internet-Draft              ALTO Requirements                 March 2009


   REQ.  RQv02-7: The ALTO client protocol MUST support the mode of
   operation, in which the ALTO client is directly embedded in the
   resource consumer.

   REQ.  RQv02-8: The ALTO client protocol MUST support the mode of
   operation, in which the ALTO client is embedded in the resource
   directory.

   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 "target-independent"
      guidance, which will be cached locally and evaluated later, when a
      resource is to be accessed.

   REQ.  RQv02-9: The ALTO client protocol MUST support at least one of
   these two modes, either the target-aware or the target-independent
   query mode.

   REQ.  RQv02-10: The ALTO client protocol SHOULD support both the
   target-aware and the target-independent query mode.

   REQ.  RQv02-11: The ALTO client protocol SHOULD support lifetime
   attributes, to enable caching of recommendations at ALTO clients.

   REQ.  RQv02-12: The ALTO client protocol SHOULD specify an aging
   mechanism, which allows to give newer recommendations precedence over
   older ones.

   REQ.  RQv02-13: 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.  RQv02-14: The ALTO client protocol MUST be designed in a way
   that different instances of the ALTO service operated by different
   providers can coexist.

   REQ.  RQv02-15: The ALTO client protocol MUST include support for
   adding protocol extensions in a non-disruptive, backward-compatible
   way.

   REQ.  RQv02-16: The ALTO client protocol MUST include protocol



Kiesel, et al.         Expires September 10, 2009              [Page 10]

Internet-Draft              ALTO Requirements                 March 2009


   versioning support, in order to clearly distinguish between
   incompatible major versions of the protocol.

3.1.3.  Error handling and overload protection

   REQ.  RQv02-17: 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.  RQv02-18: The ALTO client protocol MUST use TCP based
   transport.

   REQ.  RQv02-19: 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.  RQv02-20: 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.  RQv02-21: 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 converstation with the ALTO
   client.

   REQ.  RQv02-22: 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

   REQ.  RQv02-23: ALTO clients MUST be able to use the ALTO server
   discovery mechanism, in order to find out where to send ALTO queries.

   REQ.  RQv02-24: The ALTO server discovery mechanism SHOULD be able to
   return the respective contact information for several ALTO servers.

   REQ.  RQv02-25: The ALTO server discovery mechanism SHOULD be able to
   indicate preferences for each returned ALTO server contact
   information.

   REQ.  RQv02-26: The ALTO server discovery mechanism SHOULD be
   independent of specific link-layer protocols or access network
   architectures.  For example, many broadband access networks use DHCP
   for configuration, while others use PPPoE.  In contrast, DNS is
   available in virtually all Internet access networks.




Kiesel, et al.         Expires September 10, 2009              [Page 11]

Internet-Draft              ALTO Requirements                 March 2009


3.3.  Security and privacy

   REQ.  RQv02-27: The ALTO client protocol MUST support mechanisms for
   mutual authentication and authorization of ALTO clients and servers.

   REQ.  RQv02-28: 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.  RQv02-29: The ALTO client protocol MUST support different
   levels of detail in queries and responses, in order to protect the
   privacy of users, to ensure that the operators of ALTO servers and
   other users of the same application cannot derive sensitive
   information.

   REQ.  RQv02-30: 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.  RQv02-31: The ALTO protocol MUST include appropriate mechanisms
   to protect the ALTO service against DoS attacks.




























Kiesel, et al.         Expires September 10, 2009              [Page 12]

Internet-Draft              ALTO Requirements                 March 2009


4.  Host location attributes

   Host location attributes are used in the ALTO client protocol to
   describe the location of a host in the network topology.  The
   following list gives an overview on such attributes that have been
   proposed in the past, or which are in use by by ALTO-related
   prototype implementations.

   One possible way forward is to define the syntax and semantics of a
   mandatory set of attributes, which have to be understood by all
   entities that implement the ALTO client protocol.  Furthermore,
   defining a set of optional attributes, as well as a procedure for
   allocating new attributes (e.g., an IANA registry) may be required.
   However, there was no broad discussion of this issue so far and no
   consensus has been reached.  Therefore, the only purpose of the
   following list is to document the attributes that have been proposed
   so far, and to solicit further feedback and discussion:

   o  IP address or range of IP addresses (in CIDR notation)

   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 September 10, 2009              [Page 13]

Internet-Draft              ALTO Requirements                 March 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 following list gives an
   overview on such rating criteria that have been proposed in the past,
   or which are in use by by ALTO-related prototype implementations.

   One possible way forward is to define the syntax and semantics of a
   mandatory set of criteria, which have to be understood by all
   entities that implement the ALTO client protocol.  Furthermore,
   defining a set of optional criteria, as well as a procedure for
   allocating new criteria (e.g., an IANA registry) may be required.
   However, there was no broad discussion of this issue so far and no
   consensus has been reached.  Therefore, the only purpose of the
   following list is to document the attributes 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.

   o  Relative operator's preference: higher numerical value indicates
      that the application should prefer this candidate resource
      provider over others with lower values (if no other reasons speak
      against it, such as probed througput).  Again, as this is a
      relative measure, the ALTO service does not have to indicate how
      the values have been computed.  Examples could be: cost for
      peering or transit traffic, traffic engineering inside the own
      network, and other policies.





Kiesel, et al.         Expires September 10, 2009              [Page 14]

Internet-Draft              ALTO Requirements                 March 2009


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, throtteled, or
      charged separately at an indicated price).  The interaction of
      several applications running on a host, out of which some use this
      attribute while others don't, as well as the evaluation of this
      attribute in resource directories, which issue ALTO queries on
      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 througput from/to the candidate
      resource provider (only in ALTO replies).  This may be, but is not
      necessarily the provisioned access bandwith 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
   performace values differ significantly from these upper and lower
   bounds.  In particular, an ALTO client MUST NOT consider the "upper
   bound for througput" 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





Kiesel, et al.         Expires September 10, 2009              [Page 15]

Internet-Draft              ALTO Requirements                 March 2009


   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

   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 inacuracies 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 September 10, 2009              [Page 16]

Internet-Draft              ALTO Requirements                 March 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 September 10, 2009              [Page 17]

Internet-Draft              ALTO Requirements                 March 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.marocco-alto-problem-statement].  For a set of
   specific security requirements please refer to Section 3.3 of this
   document.












































Kiesel, et al.         Expires September 10, 2009              [Page 18]

Internet-Draft              ALTO Requirements                 March 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.marocco-alto-problem-statement]
              Seedorf, J. and E. Burger, "Application-Layer Traffic
              Optimization (ALTO) Problem Statement",
              draft-marocco-alto-problem-statement-05 (work in
              progress), March 2009.

































Kiesel, et al.         Expires September 10, 2009              [Page 19]

Internet-Draft              ALTO Requirements                 March 2009


Appendix A.  Contributors

   The authors were supported by the following people, who have
   contributed to this document:

   o  Zoran Despotovic <despotovic@docomolab-euro.com>

   o  Jason Livingood <Jason_Livingood@cable.comcast.com>

   o  Saverio Niccolini <saverio.niccolini@nw.neclab.eu>

   o  Jan Seedorf <jan.seedorf@nw.neclab.eu>

   o  Martin Stiemerling <martin.stiemerling@nw.neclab.eu>

   The authors would like to thank the members of the P2PI and ALTO
   mailing lists for their feedback.


































Kiesel, et al.         Expires September 10, 2009              [Page 20]

Internet-Draft              ALTO Requirements                 March 2009


Appendix B.  Acknowledgments

   The authors would like to thank

   o  Vijay K. Gurbani <vkg@alcatel-lucent.com>

   o  Enrico Marocco <enrico.marocco@telecomitalia.it>

   for fostering discussions that lead to the creation of this document,
   and for giving valuable comments on it.

   Sebastian Kiesel, Saverio Niccolini, Jan Seedorf, and Martin
   Stiemerling are partially supported by the NAPA-WINE project
   (Network-Aware P2P-TV Application over Wise Networks,
   http://www.napa-wine.org), a research project supported by the
   European Commission under its 7th Framework Program (contract no.
   214412).  The views and conclusions contained herein are those of the
   authors and should not be interpreted as necessarily representing the
   official policies or endorsements, either expressed or implied, of
   the NAPA-WINE project or the European Commission.

   Laird Popkin and Y. Richard Yang are grateful to the many
   contributions made by the members of the P4P working group and Yale
   Laboratory of Networked Systems.  The P4P working group is hosted by
   DCIA.


























Kiesel, et al.         Expires September 10, 2009              [Page 21]

Internet-Draft              ALTO Requirements                 March 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 September 10, 2009              [Page 22]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/