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

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

Network Working Group                                     S. Kiesel, Ed.
Internet-Draft                                                       NEC
Intended status: Informational                                 L. Popkin
Expires: January 5, 2009                            Pando Networks, Inc.
                                                              S. Previdi
                                                     Cisco Systems, Inc.
                                                               R. Woundy
                                                     Comcast Corporation
                                                               Y R. Yang
                                                         Yale University
                                                            July 4, 2008


       Application-Layer Traffic Optimization (ALTO) Requirements
                     draft-kiesel-alto-reqs-00.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 5, 2009.











Kiesel, et al.           Expires January 5, 2009                [Page 1]


Internet-Draft              ALTO Requirements                  July 2008


Abstract

   Many Internet applications are used to access resources, such as
   server processes or pieces of information, which are available in
   several equivalent replicas on different hosts.  This includes, but
   is not limited to, peer-to-peer filesharing applications.  The goal
   of Application-Layer Traffic Optimization (ALTO) is to provide
   guidance to applications, which have to select one host out of
   several candidates for providing a desired resource.  These
   recommendations shall be based on parameters that affect performance
   and efficiency of the data transmission between the hosts, e.g., the
   topological distance.  The ultimate goal is to optimize performance
   (or Quality of Experience) in the application while minimizing
   resource consumption in the underlying network infrastructure.

   This document enumerates an initial set of requirements for ALTO and
   solicits feedback and discussion.


































Kiesel, et al.           Expires January 5, 2009                [Page 2]


Internet-Draft              ALTO Requirements                  July 2008


Table of Contents

   1.  Requirements notation  . . . . . . . . . . . . . . . . . . . .  4
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  ALTO Terminology and Entities  . . . . . . . . . . . . . . . .  6
   4.  ALTO Requirements  . . . . . . . . . . . . . . . . . . . . . .  8
     4.1.  ALTO Interface . . . . . . . . . . . . . . . . . . . . . .  8
     4.2.  Error handling and overload protection for ALTO  . . . . .  9
     4.3.  Security and Privacy . . . . . . . . . . . . . . . . . . . 10
   5.  Example rating criteria  . . . . . . . . . . . . . . . . . . . 12
   6.  Open Issues  . . . . . . . . . . . . . . . . . . . . . . . . . 13
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 16
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 16
   Appendix A.  Contributors  . . . . . . . . . . . . . . . . . . . . 17
   Appendix B.  Acknowledgments . . . . . . . . . . . . . . . . . . . 18
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
   Intellectual Property and Copyright Statements . . . . . . . . . . 20































Kiesel, et al.           Expires January 5, 2009                [Page 3]


Internet-Draft              ALTO Requirements                  July 2008


1.  Requirements notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].














































Kiesel, et al.           Expires January 5, 2009                [Page 4]


Internet-Draft              ALTO Requirements                  July 2008


2.  Introduction

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

   "A significant part of the Internet traffic today is generated by
   peer-to-peer applications used for file sharing, realtime
   communications and live media streaming.  Such applications often
   deal with large amounts of data in direct peer-to-peer connections,
   but they usually have little knowledge of the underlying topology,
   both at the overlay layer and the network layer.  As a result, they
   may choose their peers based on measurements and statistics which, in
   some specific situations, often 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 optimize performance (or Quality of
   Experience) in the application while minimizing resource consumption
   in the underlying network infrastructure.

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

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












Kiesel, et al.           Expires January 5, 2009                [Page 5]


Internet-Draft              ALTO Requirements                  July 2008


3.  ALTO Terminology and Entities

   This document uses the following terms related to ALTO.

   o  Client Application: An application (e.g., P2P filesharing) that
      uses the ALTO service to optimize its performance (or Quality of
      Experience) while minimizing resource consumption in the
      underlying network infrastructure.

   o  Client Application Resource: A resource, such as a server process
      or a piece of information, which can be accessed using the Client
      Application.  It is assumed that this resource is available in
      several equivalent replicas on different Client Application
      Providers.

   o  Client Application Resource Identifier: An application layer
      identifier used to identify a Client Application Resource, no
      matter how many replicas thereof exist.

   o  Client Application Provider: A specific entity of the Client
      Application (e.g., one node of a P2P overlay), which provides a
      specific Client Application Resource.  The mechanisms used to
      spread the information that a specific Client Application entity
      is able and willing to act as Client Application Provider for a
      specific Client Application Resource are out of the scope of ALTO.

   o  Client Application Consumer: A specific entity of the Client
      Application (e.g., one node of a P2P overlay), which wants to
      access a Client Application Resource, and therefore seeks guidance
      from ALTO to select a good Client Application Provider.  The
      Client Application Consumer will eventually initiate the transfer
      of user data.

   o  Transport Address: The lower layer address information needed to
      initiate data transfer from a specific Client Application
      Provider.  This might be just an IP address.  It might also be
      augmented by, e.g., specifying the transport protocol and the port
      number.

   o  Client Application Directory: An entity which is separate from the
      Client Application Consumer, and which assists the Client
      Application Consumer to translate a Client Application Resource
      Identifier into a set of Transport Addresses, e.g., a P2P tracker.
      Some Client Applications do not use this concept and do the
      address mapping directly in the Client Application Consumer.

   o  Host Location Attribute: Information which is related to the
      location of a host in the network topology.  The ALTO service



Kiesel, et al.           Expires January 5, 2009                [Page 6]


Internet-Draft              ALTO Requirements                  July 2008


      gives recommendations based on this information.  A host location
      attribute may consist, for example, of an IP address, an address
      prefix or address range that contains the host, an autonomous
      system (AS) number, or any other localization attribute.  These
      different options may provide different levels of detail.  This
      has implications on the quality of the recommendations ALTO is
      able to provide, on whether recommendations can be aggregated, and
      on how much privacy-sensitive information about users is disclosed
      to the ALTO servers.

   o  ALTO service: If several Client Application Providers are able to
      provide the same Client Application Resource the ALTO service
      gives guidance to a Client Application Consumer, on which Client
      Application Provider to select, in order to optimize its
      performance (or Quality of Experience) while minimizing resource
      consumption in the underlying network infrastructure.

   o  ALTO server: A logical entity that provides interfaces, which can
      be used to query the ALTO service.

   o  ALTO client: The logical ALTO protocol entity that sends ALTO
      queries.  Depending on the architecture of the Client Application
      it may be embedded in the Client Application Consumer or in the
      Client Application Directory.



























Kiesel, et al.           Expires January 5, 2009                [Page 7]


Internet-Draft              ALTO Requirements                  July 2008


4.  ALTO Requirements

4.1.  ALTO Interface

   REQ. 1: The ALTO service MUST implement one or several well-defined
   interfaces, which can be queried from ALTO clients.

   REQ. 2: The ALTO clients MUST be able to query ALTO information from
   the ALTO service, which is related to network topology or other
   network properties.

   REQ. 3: ALTO clients may be embedded directly in the Client
   Application Consumer (e.g., peer of an unstructured P2P application),
   which wants to access a Client Application Resource.  However, ALTO
   queries may also be performed indirectly, via Client Application
   Directories, such as name servers, directory servers, trackers, etc.,
   which translate a Client Application Resource Identifier to a list of
   Transport Addresses.  They may use ALTO to return the "best"
   addresses to the actual Client Application Consumer.  The ALTO
   protocol MUST support both modes of operation.

   REQ. 4: ALTO Clients MUST be able to find out where to send ALTO
   queries.

   REQ. 5: The ALTO service MUST implement a query/response protocol.
   An ALTO transaction consists of a query request from an ALTO client
   to the ALTO service, and a corresponding reply.

   The request MUST contain a Host Location Attribute of the Client
   Application Consumer, i.e., the entity that will actually perform the
   data transfer from the desired Client Application Resource.  It is
   assumed that this resource, such as a server process or a piece of
   information, is available in several equivalent replicas on different
   hosts.  In the request, the ALTO client MAY present a list of
   Transport Addresses or Host Location Attributes of hosts, which are
   known to be able to provide the desired resource.  Alternatively, it
   MAY present a Client Application Resource Identifier to indicate the
   resource it wants to access.  In the latter case a mechanism, which
   is specific to the Client Application, is required first, to
   determine Transport Addresses of candidate Client Application
   Providers.

   The ALTO service rates these alternatives according to various
   criteria, such as the examples given in Section 5.

   The reply MAY contain a list of Transport Addresses or Host Location
   Attributes, which is sorted according to these criteria.
   Alternatively or additionally, the reply MAY contain quantifiable or



Kiesel, et al.           Expires January 5, 2009                [Page 8]


Internet-Draft              ALTO Requirements                  July 2008


   non-quantifiable information about every possible Client Application
   Provider, so that the ALTO client can perform the rating and decision
   itself.

   REQ. 6: The syntax and semantics of the ALTO protocol MUST be
   extensible to allow the requirements of future applications to be
   adopted.  This includes, amongst others, support for adding protocol
   extensions in a non-disruptive, backward-compatible way, as well as
   protocol versioning support to clearly distinguish between
   incompatible major versions of the protocol.

   REQ. 7: The information available from the ALTO service is not a
   replacement for congestion control mechanisms.  Applications using
   ALTO MUST ensure that they do not cause congestion in the network,
   e.g., by using TCP transport, which includes congestion control
   mechanisms.

4.2.  Error handling and overload protection for ALTO

   REQ. 8: Any application designed to use ALTO MUST also work
   reasonably if no ALTO servers can be found or if no responses to ALTO
   queries are received, e.g., due to connectivity problems or overload
   situation.

   REQ. 9: An overloaded ALTO server receiving too many requests MAY
   silently discard excess requests.

   REQ. 10: An ALTO client MAY retransmit an unanswered ALTO query after
   a reasonable time, or it MAY query a different server.  Otherwise it
   MUST report to the Client Application that it has to make its
   decision without ALTO support.

   REQ. 11: An ALTO client MUST limit the total number of unanswered
   ALTO queries on a per-server basis.  This limit MUST be reduced if a
   request times out and MAY be increased if several subsequent queries
   succeed without a timeout.

   REQ. 12: 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 Client Application that it has to make its decision
   without ALTO support.

   REQ. 13: The ALTO protocol MUST have a server overload flag in the
   reply messages.  If an ALTO server is operating close to its capacity
   limit it MAY set this flag in responses, even if it has not yet to
   discard excess query messages.  An ALTO client receiving a reply with
   the server overload flag set can use the reply for the intended



Kiesel, et al.           Expires January 5, 2009                [Page 9]


Internet-Draft              ALTO Requirements                  July 2008


   purpose (e.g., peer selection).  However, with respect to overload
   control, it MUST behave as if it had not received a reply.

   REQ. 14: The ALTO protocol MAY have a mechanism by which the client
   can specify the required level of precision.  If only a medium amount
   of data has to be retrieved, a quick answer from the ALTO server with
   a good but not necessarily optimal peer recommendation may be
   sufficient.  If, however, very large amounts of data will be
   transferred or the association will persist for an extended time, the
   client might request the ALTO service to spend more resources to make
   an optimal recommendation.

   REQ. 15: In the request, a client SHOULD be able to indicate how many
   different recommended Host Location Attributes or Transport Addresses
   of Client Application Providers it wants to receive.  An ALTO server
   SHOULD NOT send more than this number of recommended locations.  An
   ALTO server MAY send fewer than this number of recommended locations.

   REQ. 16: The ALTO protocol SHOULD support lifetime attributes, to
   enable caching of recommendations at ALTO clients.

4.3.  Security and Privacy

   REQ. 17: The ALTO protocols 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. 18: Different instances of the ALTO service operated by
   different providers must be able to coexist.

   REQ. 19: The ALTO protocol MUST support mechanisms for mutual
   authentication and authorization of ALTO clients and servers.

   REQ. 20: The ALTO protocol MUST support different levels of detail in
   queries and responses, in order for the operator of an ALTO service
   to be able to control how much information (e.g., about the network
   topology) is disclosed.

   REQ. 21: The ALTO protocol MUST support different levels of detail in
   queries and responses, in order to protect the privacy of users, so
   that the operators of ALTO servers and other users of the same Client
   Application cannot derive sensitive information.

   REQ. 22: One ALTO interface should be defined in a way, that the
   operator of one ALTO server cannot easily deduce the resource (e.g.,
   filename in P2P filesharing) which the requester wants to obtain.

   REQ. 23: The ALTO protocol MUST support encryption, in order to



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


Internet-Draft              ALTO Requirements                  July 2008


   protect the privacy of users with respect to third parties.

   REQ. 24: The ALTO protocol must be designed in a way that the ALTO
   service is protected against DoS attacks.















































Kiesel, et al.           Expires January 5, 2009               [Page 11]


Internet-Draft              ALTO Requirements                  July 2008


5.  Example rating criteria

   Alternative resources for servers or data replicas may be rated
   according to the following criteria.  This list is not exhaustive,
   and may later be moved to a separate document.

   o  topological distance, e.g., AS hop count, or whether peer is
      reachable via own network / revenue-neutral peering / global
      upstream

   o  expected cost for data transport

   Criteria that SHOULD NOT be used for rating

   o  Performance metrics related to instantaneous congestion status.
      This has to be probed and adapted to continuously, e.g., using
      TCP.


































Kiesel, et al.           Expires January 5, 2009               [Page 12]


Internet-Draft              ALTO Requirements                  July 2008


6.  Open Issues

   Is ALTO completely unaware of content, e.g., P2P filesharing file
   names?  ALTO could be combined with trackers.  As an alternative,
   trackers can ask an ALTO-backend.  Do we consider both cases?














































Kiesel, et al.           Expires January 5, 2009               [Page 13]


Internet-Draft              ALTO Requirements                  July 2008


7.  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 January 5, 2009               [Page 14]


Internet-Draft              ALTO Requirements                  July 2008


8.  Security Considerations

   High-level security considerations for the ALTO service can be found
   in the "Security Considerations" section of the ALTO problem
   statement [I-D.marocco-alto-problem-statement].  For a set of
   specific security requirements please refer to Section 4.3 of this
   document.












































Kiesel, et al.           Expires January 5, 2009               [Page 15]


Internet-Draft              ALTO Requirements                  July 2008


9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

9.2.  Informative References

   [I-D.marocco-alto-problem-statement]
              Marocco, E. and V. Gurbani, "Application-Layer Traffic
              Optimization (ALTO) Problem Statement",
              draft-marocco-alto-problem-statement-00 (work in
              progress), April 2008.





































Kiesel, et al.           Expires January 5, 2009               [Page 16]


Internet-Draft              ALTO Requirements                  July 2008


Appendix A.  Contributors

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

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

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

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

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







































Kiesel, et al.           Expires January 5, 2009               [Page 17]


Internet-Draft              ALTO Requirements                  July 2008


Appendix B.  Acknowledgments

   The authors would like to thank

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

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

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

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

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


























Kiesel, et al.           Expires January 5, 2009               [Page 18]


Internet-Draft              ALTO Requirements                  July 2008


Authors' Addresses

   Sebastian Kiesel (editor)
   NEC Europe Ltd., Network Laboratories Europe
   Kurfuersten-Anlage 36
   Heidelberg  69115
   Germany

   Phone: +49 6221 4342 232
   Email: sebastian.kiesel@nw.neclab.eu


   Laird Popkin
   Pando Networks, Inc.

   Email: laird@pando.com


   Stefano Previdi
   Cisco Systems, Inc.

   Email: sprevidi@cisco.com


   Richard Woundy
   Comcast Corporation

   Email: Richard_Woundy@cable.comcast.com


   Yang Richard Yang
   Yale University

   Email: yry@cs.yale.edu

















Kiesel, et al.           Expires January 5, 2009               [Page 19]


Internet-Draft              ALTO Requirements                  July 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.











Kiesel, et al.           Expires January 5, 2009               [Page 20]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/