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


       Application-Layer Traffic Optimization (ALTO) Requirements
                     draft-kiesel-alto-reqs-01.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 May 7, 2009.











Kiesel, et al.             Expires May 7, 2009                  [Page 1]


Internet-Draft              ALTO Requirements              November 2008


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.  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
   improve performance (or Quality of Experience) in the application
   while reducing 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 May 7, 2009                  [Page 2]


Internet-Draft              ALTO Requirements              November 2008


Table of Contents

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
































Kiesel, et al.             Expires May 7, 2009                  [Page 3]


Internet-Draft              ALTO Requirements              November 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 May 7, 2009                  [Page 4]


Internet-Draft              ALTO Requirements              November 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 example, 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
   network topology.  As a result, they may choose their peers based on
   measurements and statistics which, in some 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 "super peers" of a P2P application operated
   by the network provider, etc.













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


Internet-Draft              ALTO Requirements              November 2008


3.  ALTO Terminology and Entities

   This document uses the following ALTO-related terms, which are
   defined in [I-D.marocco-alto-problem-statement]:

   Application, Overlay Network, Peer, Resource, Resource Identifier,
   Resource Provider, Resource Consumer, Resource Directory, Transport
   Address, Host Location Attribute, ALTO Service, ALTO Server, ALTO
   Client, ALTO Query, ALTO Reply, ALTO Transaction, Local Traffic,
   Peering Traffic, Transit Traffic.









































Kiesel, et al.             Expires May 7, 2009                  [Page 6]


Internet-Draft              ALTO Requirements              November 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 information from the
   ALTO service, which provides guidance for selecting appropriate
   resource providers.

   REQ. 3: ALTO clients MUST be able to find out where to send ALTO
   queries.

   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.

   However, another mode of operation is to perform ALTO queries
   indirectly, via resource directories.  These translate a resource
   identifier to a list of resource providers with their corresponding
   transport addresses.  The resource directories may issue ALTO queries
   to solicit preference on such lists, considering the respective
   resource consumer.

   The ALTO protocol MUST support both modes of operation.  One way to
   fulfill this requirement is to include in the ALTO query a a host
   location attribute of the resource consumer, i.e., the entity that
   will eventually perform the data transfer.

   REQ. 5: 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. 6: 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. 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, e.g., due to connectivity problems or overload



Kiesel, et al.             Expires May 7, 2009                  [Page 7]


Internet-Draft              ALTO Requirements              November 2008


   situation.

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

   REQ. 9: An ALTO client MAY retransmit an unanswered ALTO query after
   a reasonable amount of time, or it MAY query a different server.
   Otherwise, or if all retransmissions or queries to different servers
   have failed as well, the ALTO client MUST report to the application
   that no ALTO information is available.  In this case, the application
   has to perform the resource provider selection without ALTO guidance.

   REQ. 10: 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. 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.  In
   this case, the application has to perform the resource provider
   selection without ALTO guidance.

   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.
   An ALTO client receiving a reply message with this overload
   indication may use the message content for the intended purpose
   (i.e., guidance with respect to resource provider selection).
   However, with respect to overload control, it MUST behave as if it
   had not received a reply.

   REQ. 13: The ALTO protocol MAY have a mechanism by which the ALTO
   client can specify the required level of precision.  If only a medium
   amount of data has to be exchanged, it may be sufficient to get a
   quick answer from the ALTO service, which results in a certain
   improvement compared to a resource provider selection without any
   ALTO guidance.  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
   a recommendation that leads to higher improvements.

   REQ. 14: The ALTO protocol SHOULD support lifetime attributes, to
   enable caching of recommendations at ALTO clients.  The ALTO protocol
   MAY specify an aging mechanism, which allows to give newer
   recommendations precedence over older ones.




Kiesel, et al.             Expires May 7, 2009                  [Page 8]


Internet-Draft              ALTO Requirements              November 2008


4.3.  Security and Privacy

   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.

   REQ. 16: Different instances of the ALTO service operated by
   different providers must be able to coexist.

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

   REQ. 18: 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. 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.

   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.

   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.

   REQ. 22: The ALTO protocol MUST include appropriate mechanisms to
   protect the ALTO service against DoS attacks.
















Kiesel, et al.             Expires May 7, 2009                  [Page 9]


Internet-Draft              ALTO Requirements              November 2008


5.  Example rating criteria

   The goal of ALTO is to provide guidance to resource consumers that
   have to select resource providers.  The recommendations may be based
   on various rating criteria.  The following list is not intended to be
   exhaustive, and it may later be moved to a separate document.

   o  Topological distance between the resource consumer and the
      candidate resource provider, e.g., the number of traversed
      autonomous systems (AS), or whether the traffic will be local
      traffic, peering traffic, or transit traffic.

   o  Expected cost for data exchange between the candidate resource
      provider and the resource consumer, according to the economic
      agreements between ISP.  They may be expressed as absolute costs
      or relative costs, compared to retrieving the same data from
      another candidate resource provider.

   Rating criteria that SHOULD NOT be used by the ALTO service include:

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


Internet-Draft              ALTO Requirements              November 2008


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 May 7, 2009                 [Page 11]


Internet-Draft              ALTO Requirements              November 2008


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 4.3 of this
   document.












































Kiesel, et al.             Expires May 7, 2009                 [Page 12]


Internet-Draft              ALTO Requirements              November 2008


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

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





































Kiesel, et al.             Expires May 7, 2009                 [Page 13]


Internet-Draft              ALTO Requirements              November 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 May 7, 2009                 [Page 14]


Internet-Draft              ALTO Requirements              November 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 May 7, 2009                 [Page 15]


Internet-Draft              ALTO Requirements              November 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 May 7, 2009                 [Page 16]


Internet-Draft              ALTO Requirements              November 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 May 7, 2009                 [Page 17]