[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: 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]
Html markup produced by rfcmarkup 1.129b, available from
https://tools.ietf.org/tools/rfcmarkup/