One document matched: draft-ietf-alto-problem-statement-02.txt
Differences from draft-ietf-alto-problem-statement-01.txt
Network Working Group J. Seedorf
Internet-Draft NEC
Intended status: Informational E. Burger
Expires: January 4, 2010 Neustar
July 3, 2009
Application-Layer Traffic Optimization (ALTO) Problem Statement
draft-ietf-alto-problem-statement-02
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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 4, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
Peer-to-peer applications, such as file sharing, real-time
communication, and live and on-demand media streaming use a
Seedorf & Burger Expires January 4, 2010 [Page 1]
Internet-Draft ALTO Problem Statement July 2009
significant amount of Internet resources. Such applications often
transfer large amounts of data in peer-to-peer connections. However,
they usually have little knowledge of the underlying network
topology. As a result, they may choose their peers randomly with
respect to the underlying network topology or they may choose their
peers based on measurements and statistics that, in many situations,
may lead to suboptimal choices. This document describes problems
related to improving traffic generated by peer-to-peer applications.
In particular, this document discusses issues which better-than-
random peer selection based on network-layer information may raise.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. State-of-the-Art . . . . . . . . . . . . . . . . . . . . . 4
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. The Problem . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. File sharing . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Cache/Mirror Selection . . . . . . . . . . . . . . . . . . 8
4.3. Live Media Streaming . . . . . . . . . . . . . . . . . . . 8
4.4. Realtime Communications . . . . . . . . . . . . . . . . . 8
4.5. Distributed Hash Tables . . . . . . . . . . . . . . . . . 9
5. Aspects of the Problem . . . . . . . . . . . . . . . . . . . . 9
5.1. ALTO Service Providers . . . . . . . . . . . . . . . . . . 9
5.2. ALTO Service Implementation . . . . . . . . . . . . . . . 9
5.3. User Privacy . . . . . . . . . . . . . . . . . . . . . . . 10
5.4. Topology Hiding . . . . . . . . . . . . . . . . . . . . . 10
5.5. Coexistence with Caching . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
10. Informative References . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Seedorf & Burger Expires January 4, 2010 [Page 2]
Internet-Draft ALTO Problem Statement July 2009
1. Introduction
1.1. Overview
Peer-to-peer (P2P) applications, such as file sharing, real-time
communication, and live and on-demand media streaming use a
significant amount of Internet resources [WWW.wired.fuel]. Different
from client/server applications, P2P applications access resources
such as files or media relays distributed across the Internet and
exchange large amounts of data in connections that they establish
directly with nodes sharing such resources.
One advantage of systems following the P2P paradigm results from the
fact that the resources such systems offer are often available
through multiple replicas. However, applications generally do not
have reliable information of the underlying network and thus have to
select among available replicas randomly or based on information they
deduce from partial observations that, in some situations, lead to
suboptimal choices. For example, one peer selection algorithm is
based only on the measurements during initial connection
establishment between two peers. Since actual data transmission does
not begin, the algorithm measures only the round-trip time and cannot
reliably deduce actual throughput between the peers. Thus, such a
peer selection algorithm that simply uses round-trip time may result
in a sub-optimal choice of peers.
Many of today's P2P systems use an overlay network consisting of
direct peer connections. Such connections often do not account for
the underlying network topology. In addition to having suboptimal
performance, such networks can lead to congestion and cause serious
inefficiencies. As shown in [ACM.fear], traffic generated by popular
P2P applications often cross network boundaries multiple times,
overloading links which are frequently subject to congestion
[ACM.bottleneck]. Moreover, such transits, besides resulting in a
poor experience for the user, can be quite costly to the network
operator.
Recent studies [ACM.ispp2p] [WWW.p4p.overview] [ACM.ono] show a
possible solution to this problem. Internet Service Providers (ISP),
network operators or third parties can collect more reliable network
information. This information includes relevant information such as
topology or bandwidth available. Normally, such information changes
on a much longer time scale than information used for congestion
control on the transport layer. Providing this information to P2P
applications can enable them to apply better-than-random peer
selection with respect to the underlying network topology. As a
result, it may be possible to increase application performance,
reduce congestion and decrease the overall amount of traffic across
Seedorf & Burger Expires January 4, 2010 [Page 3]
Internet-Draft ALTO Problem Statement July 2009
different networks. Presumably, both applications and the network
operator can benefit from such information. Thus, network operators
have an incentive to provide, either directly themselves or
indirectly through a third party, such information; applications have
an incentive to use such information. This document gives the
problem statement of improving traffic generated by P2P applications
using information provided by a separate party.
Section 2 provides definitions. Section 3 introduces the problem.
Section 4 describes some use cases where both P2P applications and
network operators benefit from a solution to such a problem.
Section 5 describes the main issues to consider when designing such a
solution. Note a companion document to this document, the ALTO
Requirements [I-D.ietf-alto-reqs], goes into the details of these
issues.
1.2. State-of-the-Art
The papers [ACM.ispp2p], [I-D.bonaventure-informed-path-selection]
and [WWW.p4p.overview] present examples of contemporary solution
proposals that address the problem described in this document.
Moreover, these proposals have encouraging simulation and field test
results. These and similar, independent, solutions all consist of
two essential parts:
o a discovery mechanism which a P2P application uses to find a
reliable information source and
o a protocol P2P applications use to query such sources in order to
retrieve the information needed to perform better-than-random
selection of the endpoints providing a desired resource.
It is not clear how such solutions will perform if deployed globally
on the Internet. However, wide adoption is unlikely without an
agreement on a common solution based upon an open standard.
2. Definitions
The following terms have special meaning in the definition of the
Application-Layer Traffic Optimization (ALTO) problem.
Application: A distributed communication system (e.g., file sharing)
that uses the ALTO service to improve its performance or quality
of experience while improving resource consumption in the
underlying network infrastructure. Applications may use the P2P
model to organize themselves, use the client-server model, or use
a hybrid of both (i.e., a mixture between the P2P model and the
client-server model).
Seedorf & Burger Expires January 4, 2010 [Page 4]
Internet-Draft ALTO Problem Statement July 2009
Peer: A specific participant in an application. Colloquially, a
peer refers to a participant in a P2P network or system, and this
definition does not violate that assumption. If the basis of the
application is the client-server or hybrid model, then the usage
of the terms "client" and "server" disambiguates the peer's role.
P2P: Peer-to-Peer.
Resource: Content (such as a file or a chunk of a file), or a server
process (for example to relay a media stream or perform a
computation), which applications can access. In the ALTO context,
a resource is often available in several equivalent replicas. In
addition, different peers share these resources, often
simultaneously.
Resource Identifier: An application layer identifier used to
identify a resource, no matter how many replicas exist.
Resource Provider: For P2P applications, a resource provider is a
specific peer that provides some resources. For client-server or
hybrid applications, a provider is a server that hosts a resource.
Resource Consumer: For P2P applications, a resource consumer is a
specific peer that needs to access resources. For client-server
or hybrid applications, a consumer is a client that needs to
access resources.
Transport Address: All address information that a resource consumer
needs to access the desired resource at a specific resource
provider. This information usually consists of the resource
provider's IP address and possibly other information, such as a
transport protocol identifier or port numbers.
Overlay Network: A virtual network consisting of direct connections
on top of another network, established by a group of peers.
Resource Directory: An entity that is logically separate from the
resource consumer that assists a resource consumer to identify a
set of resource providers. Some P2P applications refer to the
resource directory as a P2P tracker.
ALTO Service: Several resource providers may be able to provide the
same resource. The ALTO service gives guidance to a resource
consumer and/or resource directory about which resource
provider(s) to select in order to optimize the client's
performance or quality of experience while improving resource
consumption in the underlying network infrastructure.
ALTO Server: A logical entity that provides interfaces to the
queries to the ALTO service.
ALTO Client: The logical entity that sends ALTO queries. Depending
on the architecture of the application one may embed it in the
resource consumer and/or in the resource directory.
ALTO Query: A message sent from an ALTO client to an ALTO server,
which requests guidance from the ALTO Service.
Seedorf & Burger Expires January 4, 2010 [Page 5]
Internet-Draft ALTO Problem Statement July 2009
ALTO Response: A message which contains guiding information from the
ALTO service as a reply to an ALTO query.
ALTO Transaction: An ALTO transaction consists of an ALTO query and
the corresponding ALTO response.
Local Traffic: Traffic that stays within the network infrastructure
of one Internet Service Provider (ISP). This type of traffic
usually results in the least cost for the ISP.
Peering Traffic: Internet traffic exchanged by two Internet Service
Providers whose networks connect directly. Apart from
infrastructure and operational costs, peering traffic is often
free to the ISPs, within the contract of a peering agreement.
Transit Traffic: Internet traffic exchanged on the basis of economic
agreements amongst Internet Service Providers (ISP). An ISP
generally pays a transit provider for the delivery of traffic
flowing between its network and remote networks to which the ISP
does not have a direct connection.
Application Protocol: A protocol used by the application for
establishing an overlay network between the peers and exchanging
data on it, as well as for data exchange between peers and
resource directories if applicable. These protocols play an
important role in the overall ALTO architecture. However,
defining them is out of the scope of the ALTO WG.
ALTO Client Protocol: The protocol used for sending ALTO queries and
ALTO replies between an ALTO client and ALTO Server.
Provisioning Protocol: A protocol used for populating the ALTO
server with information.
+------+
+-----+ | Peers
+-----+ +------+ +=====| |--+
| |.......| |====+ +--*--+
+-----+ +------+ | *
Source of ALTO | *
Information Server | +--*--+
+=====| | Resource Directory
+-----+ (Tracker, proxy)
Legend:
=== ALTO client protocol
*** Application protocol (out of scope)
... Provisioning or initialization (out of scope)
Figure 1 - Overview of protocol interaction between ALTO elements
Figure 1 shows the scope of the ALTO client protocol: Peers or
resource directories can use such a protocol as ALTO-clients to query
Seedorf & Burger Expires January 4, 2010 [Page 6]
Internet-Draft ALTO Problem Statement July 2009
an ALTO-server. The mapping of topological information onto an ALTO
service as well as the application protocol interaction between peers
and resource directories are out of scope for the ALTO client
protocol.
3. The Problem
Network engineers have been facing the problem of traffic
optimization for a long time and have designed mechanisms like MPLS
[RFC3031] and DiffServ [RFC3260] to deal with it. The problem these
protocols address consists in finding (or setting) optimal routes for
packets traveling between specific source and destination addresses
and based on requirements such as low latency, high reliability, and
priority. Such solutions are usually implemented at the link and
network layers, and tend to be almost transparent. At best,
applications can only "mark" the traffic they generate with the
corresponding properties.
However, P2P applications that are today posing serious challenges to
Internet infrastructures cannot directly use the aforementioned
techniques. By cooperating with external services that are aware of
the network topology, P2P applications could greatly improve the
traffic they generate. In fact, when a P2P application needs to
establish a connection, the logical target is not a host, but rather
a resource (e.g., a file or a media relay) that can be available in
multiple instances on different peers. Selection of a good host from
an overlay topological proximity has a large impact on the overall
traffic generated.
Better-than-random peer selection is helpful in the initial phase of
the process. Consider a P2P protocol in which a querying peer
receives a list of candidate destinations where a resource resides.
From this list, the peer will derive a smaller set of candidates to
connect to and exchange information with. In another example, a
streaming video client may be provided with a list of destinations
from which it can stream content. In both cases, the use of topology
information in an early stage will allow applications to improve
their performance and will help ISPs make a better use of their
network resources. In particular, an economic goal for ISPs is to
reduce the transit traffic on interdomain links.
Addressing the Application-Layer Traffic Optimization (ALTO) problem
means, on the one hand, deploying an ALTO service to provide
applications with information regarding the underlying network and,
on the other hand, enhancing applications in order to use such
information to perform better-than-random selection of the endpoints
they establish connections with.
Seedorf & Burger Expires January 4, 2010 [Page 7]
Internet-Draft ALTO Problem Statement July 2009
4. Use Cases
4.1. File sharing
File sharing applications allow users to search for content shared by
other users and to download respective resources from other users.
For instance, search results can consist of many instances of the
same file (or chunk of a file) available from multiple sources. The
goal of an ALTO solution is to help peers find the best ones
according to the underlying networks.
On the application side, integration of ALTO functionalities may
happen at different levels. For example, in the completely
decentralized Gnutella network, selection of the best sources is
totally up to the user. In systems like BitTorrent and eDonkey,
central elements such as trackers or servers act as mediators.
Therefore, in the former case, improvement would require modification
in the applications, while in the latter it could just be implemented
in some central elements.
4.2. Cache/Mirror Selection
Providers of popular content like media and software repositories
usually resort to geographically distributed caches and mirrors for
load balancing. Selection of the proper mirror/cache for a given
user is today based on inaccurate geolocation data, on proprietary
network location systems or often delegated to the user herself. An
ALTO solution could be easily adopted to ease such a selection in an
automated way.
4.3. Live Media Streaming
P2P applications for live streaming allow users to receive multimedia
content produced by one source and targeted to multiple destinations,
in a real-time or near-real-time way. This is particularly important
for users or networks that do not support multicast. Peers often
participate in the distribution of the content, acting as both
receivers and senders. The goal of an ALTO solution is to help a
peer to find effective communicating peers that exchange the media
content.
4.4. Realtime Communications
P2P real-time communications allow users to establish direct media
flows for real-time audio, video, and real-time text calls or to have
text chats. In the basic case, media flows directly between the two
endpoints. However, unfortunately a significant portion of users
have limited access to the Internet due to NATs, firewalls or
Seedorf & Burger Expires January 4, 2010 [Page 8]
Internet-Draft ALTO Problem Statement July 2009
proxies. Thus, other elements need to relay the media. Such media
relays are distributed over the Internet with a public addresses. An
ALTO solution needs to help peers to find the best relays.
4.5. Distributed Hash Tables
Distributed hash tables (DHT) are a class of overlay algorithms used
to implement lookup functionalities in popular P2P systems, without
using centralized elements. In such systems, a peer maintains the
addresses of a set of other peers participating in the same DHT in a
routing table, sorted according to specific criteria. An ALTO
solution can provide valuable information for DHT algorithms.
5. Aspects of the Problem
This section introduces some aspects of the problem that some people
may not be aware of when they first start studying the problem space.
The goal of an ALTO service is to provide applications with
information they can use to perform better-than-random peer
selection.
5.1. ALTO Service Providers
At least three different kinds of entities can provide ALTO services:
1. Network operators. Network operators usually have full knowledge
of the network they administer and are aware of their network
topology and policies.
2. Third parties. Third parties are entities separate from network
operators, but which may have either collected network
information or have arrangements with network operators to learn
the network information. Examples of such entities are content
delivery networks like Akamai, which control wide and highly
distributed infrastructures, or companies providing an ALTO
service on behalf of ISPs.
3. User communities. User communities run distributed algorithms,
for example for estimating the topology of the Internet.
5.2. ALTO Service Implementation
It is important for the reader to understand there are significant
user communities that expect an ALTO Server to be a centralized
service. Likewise, there are other user communities to expect that
the ALTO service be a distributed service, possibly even based on or
integrating with a P2P service.
A result of this is one can reasonably expect there to be some sort
Seedorf & Burger Expires January 4, 2010 [Page 9]
Internet-Draft ALTO Problem Statement July 2009
of service discovery mechanism to go along with the ALTO protocol
definition.
5.3. User Privacy
On the one hand, there are data elements an ALTO client could provide
in its query to an ALTO server that could help increase the level of
accuracy in the replies. For example, if the querying client
indicates what kind of application it is using (e.g. real-time
communications or bulk data transfer), the server will be able to
indicate priorities in its replies accommodating the requirements of
the traffic the application will generate. On the other hand,
applications might consider such information private. In addition,
some applications may not know a priori what kind of request they
will be making.
5.4. Topology Hiding
Operators, with their intimate knowledge of their network topology,
can play an important role in addressing the ALTO problem. However,
operators often consider revealing details of such network
information to be confidential.
5.5. Coexistence with Caching
Caching is an approach to improving traffic generated by applications
that require large amounts of data transfers. In some cases, such
techniques have proven to be extremely effective in both enhancing
user experience and saving network resources.
A cache, either explicitly or transparently, replaces the content
source. Thus, a cache must in principle use and support the same
protocol as the querying peer. That is, if a cache stores web
content, it must present an HTTP interface to the web client. Any
cache solution for a given protocol needs to present that same
protocol to the client. Said differently, each caching solution for
a different protocol needs to implement that specific protocol. For
this reason, one can only reasonably expect caching solutions for the
most popular protocols, such as HTTP and BitTorrent.
It is extremely important to realize that caching and ALTO are
entirely orthogonal. ALTO, especially if it is aware of caches, can
in fact direct clients to nearby caches where the user could get a
much better quality of experience.
Seedorf & Burger Expires January 4, 2010 [Page 10]
Internet-Draft ALTO Problem Statement July 2009
6. Security Considerations
This document is neither a requirements document nor a protocol
specification. However, we believe it is important for the reader to
understand areas of security and privacy that will be important for
the design and implementation of an ALTO solution. Moreover, issues
such as digital rights management are out of scope for ALTO, as they
are not technically enforceable at this level.
The approach proposed in this document asks P2P applications to
delegate a portion of their routing capability to third parties.
This gives the third party a significant role in P2P systems.
In the case where the network operator deploys an ALTO solution, it
the P2P community might consider it hostile because the operator
could, for example:
o use ALTO to prevent content distribution and enforce copyrights;
o redirect applications to corrupted mediators providing malicious
content;
o track connections to perform content inspection or logging; and
o apply policies based on criteria other than network efficiency.
For example, the service provider may suggest routes sub-optimal
from the user's perspective to avoid peering points regulated by
inconvenient economic agreements.
It is important to note there is no protocol mechanism to require
ALTO for P2P applications. If, for some reason, ALTO fails to
improve the performance of P2P applications, ALTO will not gain
popularity and the P2P community will not use it.
At the time of this writing, the privacy issues described in the
previous section are relevant for an ALTO solution. Users may be
reluctant to disclose sensitive information to an ALTO server.
Operators, on the other hand, may not wish to disclose information
that would expose details of their interior topology. When exploring
the solution space in detail, one needs to consider these issues so
that an ALTO protocol does not presume mandatory information
disclosure, by either clients or servers.
7. IANA Considerations
None.
8. Contributors
The basis of this document is draft-marocco-alto-problem-statement,
Seedorf & Burger Expires January 4, 2010 [Page 11]
Internet-Draft ALTO Problem Statement July 2009
written by Enrico Marocco and Vijay Gurbani. They continue to
provide significant edits and inputs to the current document editors.
9. Acknowledgments
Vinay Aggarwal and the P4P working group conducted the research work
done outside the IETF. Emil Ivov, Rohan Mahy, Anthony Bryan,
Stanislav Shalunov, Laird Popkin, Stefano Previdi, Reinaldo Penno,
Dimitri Papadimitriou, Sebastian Kiesel, Greg DePriest and many
others provided insightful discussions, specific comments and much
needed corrections.
Jan Seedorf and Sebastian Kiesel 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.
Thanks in particular to Richard Yang for several reviews.
10. Informative References
[ACM.bottleneck]
Akella, A., Seshan, S., and A. Shaikh, "An Empirical
Evaluation of WideArea Internet Bottlenecks", Proceedings
of ACM SIGCOMM, October 2003.
[ACM.fear]
Karagiannis, T., Rodriguez, P., and K. Papagiannaki,
"Should ISPs fear Peer-Assisted Content Distribution?",
In ACM USENIX IMC, Berkeley 2005.
[ACM.ispp2p]
Aggarwal, V., Feldmann, A., and C. Scheideler, "Can ISPs
and P2P systems co-operate for improved performance?", In
ACM SIGCOMM Computer Communications Review
(CCR), 37:3, pp. 29-40.
[ACM.ono] Choffnes, D. and F. Bustamante, "Taming the Torrent: A
practical approach to reducing cross-ISP traffic in P2P
systems", Proceedings of ACM SIGCOMM, August 2008.
[I-D.bonaventure-informed-path-selection]
Seedorf & Burger Expires January 4, 2010 [Page 12]
Internet-Draft ALTO Problem Statement July 2009
Saucez, D. and B. Donnet, "The case for an informed path
selection service",
draft-bonaventure-informed-path-selection-00 (work in
progress), February 2008.
[I-D.ietf-alto-reqs]
Kiesel, S., Popkin, L., Previdi, S., Woundy, R., and Y.
Yang, "Application-Layer Traffic Optimization (ALTO)
Requirements", draft-ietf-alto-reqs-00 (work in progress),
April 2009.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001.
[RFC3260] Grossman, D., "New Terminology and Clarifications for
Diffserv", RFC 3260, April 2002.
[SIGCOMM.resprox]
Gummadi, K., Gummadi, R., Ratnasamy, S., Gribble, S.,
Shenker, S., and I. Stoica, "The impact of DHT routing
geometry on resilience and proximity", Proceedings of ACM
SIGCOMM, August 2003.
[WWW.p4p.overview]
Xie, H., Krishnamurthy, A., Silberschatz, A., and R. Yang,
"P4P: Explicit Communications for Cooperative Control
Between P2P and Network Providers",
<http://www.dcia.info/documents/P4P_Overview.pdf>.
[WWW.wired.fuel]
Glasner, J., "P2P fuels global bandwidth binge",
<http://www.wired.com/techbiz/media/news/2005/04/67202>.
Authors' Addresses
Jan Seedorf
NEC Laboratories Europe, NEC Europe Ltd.
Kurfuersten-Anlage 36
Heidelberg 69115
Germany
Phone: +49 (0) 6221 4342 221
Email: jan.seedorf@nw.neclab.eu
URI: http://www.nw.neclab.eu
Seedorf & Burger Expires January 4, 2010 [Page 13]
Internet-Draft ALTO Problem Statement July 2009
Eric W. Burger
Neustar
USA
Phone:
Fax: +1 530 267 7447
Email: eburger@standardstrack.com
URI: http://www.standardstrack.com
Seedorf & Burger Expires January 4, 2010 [Page 14]
| PAFTECH AB 2003-2026 | 2026-04-23 05:25:55 |