One document matched: draft-kiesel-alto-reqs-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-24 04:44:13 |