One document matched: draft-marocco-alto-problem-statement-05.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<rfc category="info" docName="draft-marocco-alto-problem-statement-05"
ipr="trust200811">
<front>
<title abbrev="ALTO Problem Statement">Application-Layer Traffic
Optimization (ALTO) Problem Statement</title>
<author fullname="Jan Seedorf" initials="J." surname="Seedorf">
<organization abbrev="NEC">NEC Laboratories Europe, NEC Europe
Ltd.</organization>
<address>
<postal>
<street>Kurfuersten-Anlage 36</street>
<city>Heidelberg</city>
<code>69115</code>
<country>Germany</country>
</postal>
<phone>+49 (0) 6221 4342 221</phone>
<email>jan.seedorf@nw.neclab.eu</email>
<uri>http://www.nw.neclab.eu</uri>
</address>
</author>
<author fullname="Eric W. Burger" initials="E.W." surname="Burger">
<organization>This Space for Sale</organization>
<address>
<postal>
<street></street>
<city></city>
<region>New Hampshire</region>
<code></code>
<country>USA</country>
</postal>
<phone></phone>
<facsimile>+1 530 267 7447</facsimile>
<email>eburger@standardstrack.com</email>
<uri>http://www.standardstrack.com</uri>
</address>
</author>
<date day="8" month="March" year="2009" />
<abstract>
<t>Peer-to-peer applications, such as file sharing, real-time
communication, and live media streaming, use a significant amount of
Internet resources. Such applications often transfer large amounts of
data in direct peer-to-peer connections. However, they usually have
little knowledge of the underlying network topology. As a result, 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 optimizing traffic generated by peer-to-peer
applications and associated issues such optimizations raise in the use
of network-layer information.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>Peer-to-peer (P2P) applications, such as file sharing, real-time
communication, and live media streaming, use a significant amount of
Internet resources <xref target="WWW.cachelogic.picture"></xref> <xref
target="WWW.wired.fuel"></xref>. Different from the client/server
architecture, 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.</t>
<t>One advantage of P2P systems 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 instances
based on information they deduce from empirical measurements that, in
some situations, lead to suboptimal choices. For example, one popular
metric is an estimation of round-trip time. This choice occurs before
actual data transmission begins and thus before the peer can deduce
actual throughput. This is one reason why a peer selection
algorithm that simply uses round-trip time often results in a
sub-optimal choice of peers.</t>
<t>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 <xref target="ACM.fear"></xref>, traffic
generated by popular P2P applications often cross network boundaries
multiple times, overloading links which are frequently subject to
congestion <xref target="ACM.bottleneck"></xref>. Moreover, such
transits, besides resulting in a poor experience for the user, can be
quite costly to the network operator.</t>
<t>Recent studies <xref target="ACM.ispp2p"></xref> <xref
target="WWW.p4p.overview"></xref> <xref target="ACM.ono"></xref> show a
possible solution to this problem. Internet Service Providers (ISP),
network operators or third parties can collect reliable network
information. This information includes relevant information such as
topology or instantaneous bandwidth available. Normally, such information is rather "static", i.e., information which can change over time but on a much longer time scale than information used for congestion control on the transport layer.
By providing this information to P2P applications, it would be possible to greatly
increase application performance, reduce congestion and optimize the
overall traffic across different networks. Presumably both, the application and the network operator, can benefit from the fact that such information is being provided to (and used by) the application. Thus, network operators have an incentive to provide (either directly themselves or indirectly through a third party) such information and applications have an incentive to use such information.
This document gives the problem statement of optimizing traffic generated by P2P applications
using information provided by a separate party.</t>
<t><xref target="problem"></xref> introduces the problem. <xref
target="usecases"></xref> describes some use cases where both P2P
applications and network operators would benefit from a solution to such
a problem. <xref target="solution"></xref> describes the main issues to
consider when designing such a solution.</t>
<section title="Research or Engineering?">
<t>The papers <xref
target="I-D.bonaventure-informed-path-selection"></xref> and <xref
target="ACM.ispp2p"></xref> <xref target="WWW.p4p.overview"></xref>
are 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: <list
style="symbols">
<t>a discovery mechanism which a P2P application uses to find a
reliable information source;</t>
<t>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.</t>
</list></t>
<t>It is not easy to foresee how such solutions would perform in the
Internet, but a more accurate evaluation would require representative
data collected from real systems by a critical mass of users.</t>
<t>However, wide adoption will probably never happen without an
agreement on a common solution based on an open standard.</t>
</section>
</section>
<section title="Definitions">
<t>The following terms have special meaning in the definition of the
Application-Layer Traffic Optimization (ALTO) problem.</t>
<t><list style="hanging">
<t hangText="Application:">A distributed communication system (e.g.,
file sharing) that uses the ALTO service to improve its performance
(or quality of experience) while optimizing 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.</t>
<t hangText="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.</t>
<t hangText="P2P:">Peer-to-Peer.</t>
<t hangText="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.</t>
<t hangText="Resource Identifier:">An application layer identifier
used to identify a resource, no matter how many replicas exist.</t>
<t hangText="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.</t>
<t hangText="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.</t>
<t hangText="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.</t>
<t hangText="Overlay Network:">A virtual network consisting of
direct connections on top of another network, established by a group
of peers.</t>
<t hangText="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.</t>
<t hangText="Host Location Attribute:">Information about the
location of a host in the network topology. The ALTO service gives
recommendations based on this information. A host location attribute
may consist of, for example, 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. Depending on the system
architecture, this may have 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 might be disclosed to additional parties.</t>
<t hangText="ALTO Service:">Several resource providers may be able
to provide the same resource. The ALTO service gives guidance to a
resource consumer or resource directory about which resource
provider(s) to select, in order to optimize the client's performance
or quality of experience while optimizing resource consumption in
the underlying network infrastructure.</t>
<t hangText="ALTO Server:">A logical entity that provides interfaces
to query the ALTO service.</t>
<t hangText="ALTO Client:">The logical entity that sends ALTO
queries. Depending on the architecture of the application one may
embed it in the resource consumer or in the resource directory.</t>
<t hangText="ALTO Query:">A message sent from an ALTO client to an
ALTO server, which requests guidance from the ALTO Service.</t>
<t hangText="ALTO Response:">A message sent from an ALTO server to
an ALTO client, which contains guiding information from the ALTO
service.</t>
<t hangText="ALTO Transaction:">An ALTO transaction consists of an
ALTO query and the corresponding ALTO response.</t>
<t hangText="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.</t>
<t hangText="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.</t>
<t hangText="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 that the ISP
does not have a direct connection.</t>
<t hangText="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."></t>
<t hangText="ALTO Client Protocol:">The protocol used for sending ALTO queries and ALTO
replies between ALTO client and ALTO Server.</t>
<t hangText="Provisioning Protocol:">A protocol used for populating the
ALTO server with topology-related information.</t>
<t hangText="Inter-ALTO Server Protocol:">The protocol used for synchronization,
query forwarding, or referral between ALTO servers that have been
provisioned with only partial knowledge of the topology-related
information (e.g., on a per-domain basis).</t>
</list></t>
<figure align="center"
title="Figure 1 - Overview of protocol interaction between ALTO elements">
<artwork><![CDATA[
+------+
+-----+ | Peers
+-----+ +------+ +=====| |--+
| |.......| |====+ +--*--+
+-----+ +------+ | *
Source of ALTO | *
topological service | +--*--+
information +=====| | Super-peer
+-----+ (Tracker, proxy)
Legend:
=== ALTO client protocol
*** Application protocol (out of scope)
... Provisioning or initialization (out of scope)
]]></artwork>
</figure>
<t>Figure 1 shows the scope of the ALTO client protocol: Peers or super-peers
can use such a protocol to query an ALTO-service. The mapping of
topological information onto an ALTO service as well as the application protocol
interaction between peers and super-peers are out of scope for the ALTO
client protocol.</t>
</section>
<section anchor="problem" title="The Problem">
<t>Network engineers have been facing the problem of traffic
optimization for a long time and have designed mechanisms like <xref
target="RFC3031">MPLS</xref> and <xref target="RFC3260">DiffServ</xref>
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.</t>
<t>However, P2P applications that are today posing serious challenges to
Internet infrastructures do not benefit much from the above route-based
techniques. Cooperating with external services aware of the network
topology could greatly optimize the traffic the P2P application
generates. 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 is often available in multiple
instances on different peers. Selection of the closest one -- or, in
general, the best from an overlay topological proximity -- has much more
impact on the overall traffic than the route followed by its packets to
reach the endpoint.</t>
<t>Optimization of peer selection is particularly important in the
initial phase of the process. Consider a P2P protocol such as
BitTorrent, where 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.</t>
<t>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.</t>
</section>
<section anchor="usecases" title="Use Cases">
<section title="File sharing">
<t>File sharing applications allow users to search for content shared
by other users and download it. Typically, search results 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.</t>
<t>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, optimization would require modification
in the applications, while in the latter it could just be implemented
in some central elements.</t>
</section>
<section title="Cache/Mirror Selection">
<t>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 himself. An ALTO
solution could be easily adopted to ease such a selection in an
automated way.</t>
</section>
<section title="Live Media Streaming">
<t>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 peers to find the best sources and the best destinations for
media flows they receive and relay.</t>
</section>
<section title="Realtime Communications">
<t>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 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.</t>
</section>
<section title="Distributed Hash Tables">
<t>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, peers maintain
addresses of other peers participating in the same DHT in a routing
table, sorted according to specific criteria. An ALTO solution will
provide valuable information for DHT algorithms.</t>
</section>
</section>
<section anchor="solution" title="The Problem in Detail">
<t>This section introduces some aspects to keep in consideration when
designing an ALTO service to provide applications with information they
can use to perform better-than-random peer selection.</t>
<section title="ALTO Service Providers">
<t>At least three different kinds of entities can provide ALTO
services: <list style="numbers">
<t>Network operators: usually have full knowledge of the network
they administer and are aware of the topology and policies that
transit and peering traffic are subject to;</t>
<t>Third parties: are entities different from the network
operators, but which may have collected 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 (and thus
acquire the information from the ISPs themselves);</t>
<t>User communities: run distributed algorithms, for example for
estimating the topology of the Internet.</t>
</list></t>
</section>
<section title="Discovery of ALTO servers">
<t>As a direct consequence of the totally decentralized architecture
of the Internet, it seems almost impossible to centralize all
information P2P applications may need to optimize traffic they
generate. Therefore, any solution for the ALTO problem will need to
specify a mechanism for applications to find a proper ALTO server to
query.</t>
<t>It is important to note that, depending on the implementation of
the ALTO service, an ALTO server could be a centralized entity, for
example deployed by the network operator, as well as a ephemeral node
participating in a distributed algorithm.</t>
</section>
<section title="User Privacy">
<t>Information provided by the ALTO client querying the ALTO server
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. However, it
is important that for using an ALTO service the application does not
have to disclose information it may consider sensitive.</t>
</section>
<section title="Topology Hiding">
<t>Operators can play an important role in addressing the ALTO
problem, but they generally consider network information they own to
be confidential. Therefore, in order to succeed and achieve wide
adoption, any solution should provide a method to help P2P
applications in peer selection without explicitly disclosing topology
of the underlying network.</t>
</section>
<section title="Coexistence with Caching">
<t>Caching is a common approach to optimizing traffic generated by
applications that require large data transfers. In some cases, such
techniques have proven to be extremely effective in both enhancing
user experience and saving network resources. However, they have two
main limits in respect to the solutions based on the provision of
topology information: <list style="numbers">
<t>Application specificity: since a cache is meant to replace the
source of the content being accessed -- either explicitly or
transparently -- it must be able to speak the same protocol with
the querying peer. For this reason, caching solutions can be
reasonably adopted only for the most popular applications, such as
HTTP and BitTorrent.</t>
<t>Content awareness: since caches need to store the content being
delivered, they are subject to legal issues whenever the user does
not have the right to access or distribute such content. This
limitation makes caching approaches that do not (or cannot)
support digital rights management unusable for distributing
copyrighted material. Since, it is very difficult for an abstract
file sharing proxy to know all of the legal parameters around
distributing content, this makes caching unusable for many
file-sharing systems. Since this is a legal and not technical
issue, the solution would be at the legal, not network, layer.</t>
</list></t>
<t>In general, solutions based on provision of topology information
need not interfere with caching. In fact, if the ALTO service used by
applications is aware of the presence of caches, the service can
indicate this in its response, marking them with higher priorities to
achieve greater optimization.</t>
</section>
</section>
<section title="Security Considerations">
<t>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.</t>
<t>In the case where the network operator deploys an ALTO solution, it
is conceivable that the P2P community would consider it hostile because
the operator could, for example: <list style="symbols">
<t>redirect applications to corrupted mediators providing malicious
content;</t>
<t>track connections to perform content inspection or logging;
and</t>
<t>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.</t>
</list></t>
<t>It is important to note that ALTO is completely optional for P2P
applications and its purpose is to help improve performance of such
applications. If, for some reason, it fails to achieve this purpose, it
would simply fail to gain popularity and the P2P community would not use
it.</t>
<t>Even in cases where the ALTO service provider maliciously alters
results returned by queries after ALTO has gained popularity (i.e., the
service provider plays well for a while to become popular and then
starts misbehaving), it would be easy for P2P application maintainers
and users to revert to solutions that are not using it.</t>
</section>
<section title="IANA Considerations">
<t>None.</t>
</section>
<section title="Acknowledgments">
<t>The basis of this document is draft-marocco-alto-problem-statement, written by Enrico Marocco and Vijay Gurbani. The authors of this draft continued editing the previous version in
agreement with the original authors.</t>
<t>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, and many others provided insightful
discussions, specific comments and much needed corrections.</t>
<t>Thanks in particular to Richard Yang for several reviews.</t>
</section>
</middle>
<back>
<references title="Informative References">
<reference anchor="SIGCOMM.resprox">
<front>
<title>The impact of DHT routing geometry on resilience and
proximity</title>
<author fullname="Krishna Gummadi" initials="K." surname="Gummadi">
<organization />
</author>
<author fullname="Ramakrishna Gummadi" initials="R."
surname="Gummadi">
<organization />
</author>
<author fullname="Sylvia Ratnasamy" initials="S."
surname="Ratnasamy">
<organization />
</author>
<author fullname="Steve Gribble" initials="S." surname="Gribble">
<organization />
</author>
<author fullname="Scott Shenker" initials="S." surname="Shenker">
<organization />
</author>
<author fullname="Ion Stoica" initials="I." surname="Stoica">
<organization />
</author>
</front>
<seriesInfo name="" value="Proceedings of ACM SIGCOMM, August 2003" />
</reference>
<reference anchor="ACM.ispp2p">
<front>
<title>Can ISPs and P2P systems co-operate for improved
performance?</title>
<author fullname="Vinay Aggarwal" initials="V." surname="Aggarwal">
<organization></organization>
</author>
<author fullname="Anja Feldmann" initials="A." surname="Feldmann">
<organization></organization>
</author>
<author fullname="Christian Scheideler" initials="C."
surname="Scheideler">
<organization></organization>
</author>
<date />
</front>
<seriesInfo name=""
value="In ACM SIGCOMM Computer Communications Review (CCR), 37:3, pp. 29-40" />
</reference>
<reference anchor="ACM.fear">
<front>
<title>Should ISPs fear Peer-Assisted Content Distribution?</title>
<author fullname="Thomas Karagiannis" initials="T."
surname="Karagiannis">
<organization></organization>
</author>
<author fullname="Pablo Rodriguez" initials="P." surname="Rodriguez">
<organization></organization>
</author>
<author fullname="Konstantina Papagiannaki" initials="K."
surname="Papagiannaki">
<organization></organization>
</author>
<date />
</front>
<seriesInfo name="" value="In ACM USENIX IMC, Berkeley 2005" />
</reference>
<reference anchor="ACM.bottleneck">
<front>
<title>An Empirical Evaluation of WideArea Internet
Bottlenecks</title>
<author fullname="Aditya Akella" initials="A." surname="Akella">
<organization></organization>
</author>
<author fullname="Srinivasan Seshan" initials="S." surname="Seshan">
<organization></organization>
</author>
<author fullname="Anees Shaikh" initials="A." surname="Shaikh">
<organization></organization>
</author>
<date />
</front>
<seriesInfo name="" value="Proceedings of ACM SIGCOMM, October 2003" />
</reference>
<reference anchor="ACM.ono">
<front>
<title>Taming the Torrent: A practical approach to reducing
cross-ISP traffic in P2P systems</title>
<author fullname="David Choffnes" initials="D." surname="Choffnes">
<organization></organization>
</author>
<author fullname="Fabian E. Bustamante" initials="F. E."
surname="Bustamante">
<organization></organization>
</author>
<date />
</front>
<seriesInfo name="" value="Proceedings of ACM SIGCOMM, August 2008" />
</reference>
<reference anchor="WWW.p4p.overview"
target="http://www.dcia.info/documents/P4P_Overview.pdf">
<front>
<title>P4P: Explicit Communications for Cooperative Control Between
P2P and Network Providers</title>
<author fullname="Haiyong Xie" initials="H." surname="Xie">
<organization></organization>
</author>
<author fullname="Arvind Krishnamurthy" initials="A."
surname="Krishnamurthy">
<organization></organization>
</author>
<author fullname="Avi Silberschatz" initials="A."
surname="Silberschatz">
<organization></organization>
</author>
<author fullname="Richard Yang" initials="R." surname="Yang">
<organization></organization>
</author>
<date />
</front>
</reference>
<reference anchor="WWW.cachelogic.picture"
target="http://www.cachelogic.com">
<front>
<title>The true picture of peer-to-peer filesharing</title>
<author fullname="Andrew Parker" initials="A." surname="Parker">
<organization></organization>
</author>
<date />
</front>
</reference>
<reference anchor="WWW.wired.fuel"
target="http://www.wired.com/techbiz/media/news/2005/04/67202">
<front>
<title>P2P fuels global bandwidth binge</title>
<author fullname="Joanna Glasner" initials="J." surname="Glasner">
<organization></organization>
</author>
<date />
</front>
</reference>
<reference anchor="RFC3031">
<front>
<title>Multiprotocol Label Switching Architecture</title>
<author fullname="E. Rosen" initials="E." surname="Rosen">
<organization></organization>
</author>
<author fullname="A. Viswanathan" initials="A."
surname="Viswanathan">
<organization></organization>
</author>
<author fullname="R. Callon" initials="R." surname="Callon">
<organization></organization>
</author>
<date month="January" year="2001" />
<abstract>
<t>This document specifies the architecture for Multiprotocol
Label Switching (MPLS). [STANDARDS TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3031" />
<format octets="147175"
target="ftp://ftp.isi.edu/in-notes/rfc3031.txt" type="TXT" />
</reference>
<reference anchor="RFC3260">
<front>
<title>New Terminology and Clarifications for Diffserv</title>
<author fullname="D. Grossman" initials="D." surname="Grossman">
<organization></organization>
</author>
<date month="April" year="2002" />
<abstract>
<t>This memo captures Diffserv working group agreements concerning
new and improved terminology, and provides minor technical
clarifications. It is intended to update RFC 2474, RFC 2475 and
RFC 2597. When RFCs 2474 and 2597 advance on the standards track,
and RFC 2475 is updated, it is intended that the revisions in this
memo will be incorporated, and that this memo will be obsoleted by
the new RFCs. This memo provides information for the Internet
community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3260" />
<format octets="21900" target="ftp://ftp.isi.edu/in-notes/rfc3260.txt"
type="TXT" />
</reference>
<reference anchor="I-D.bonaventure-informed-path-selection">
<front>
<title>The case for an informed path selection service</title>
<author fullname="Damien Saucez" initials="D" surname="Saucez">
<organization></organization>
</author>
<author fullname="Benoit Donnet" initials="B" surname="Donnet">
<organization></organization>
</author>
<date day="18" month="February" year="2008" />
<abstract>
<t>With today's peer-to-peer applications, more and more content
is available from multiple sources. In tomorrow's Internet hosts
will have multiple paths to reach one destination host with the
deployment of dual-stack IPv4/IPv6 hosts, but also with new
techniques such as shim6 or other locator/identifier mechanisms
being discussed within the IRTF RRG. All these hosts will need to
rank paths in order to select the best paths to reach a given
destination/content. In this draft, we propose an informed path
selection service that would be queried by hosts and would rank
paths based on policies and performance metrics defined by the
network operator to meet his traffic engineering objectives. A
companion document describes a protocol that implements this
service.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft"
value="draft-bonaventure-informed-path-selection-00" />
<format target="http://www.ietf.org/internet-drafts/draft-bonaventure-informed-path-selection-00.txt"
type="TXT" />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 21:40:18 |