One document matched: draft-marocco-alto-problem-statement-03.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfcXXXX.dtd">
<rfc docName="DOCNAME" category="info" ipr="full3978">
<?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" ?>
<front>
<title abbrev="ALTO Problem Statement">
Application-Layer Traffic Optimization (ALTO) Problem Statement
</title>
<author initials="E." surname="Marocco" fullname="Enrico Marocco">
<organization>Telecom Italia</organization>
<address>
<postal>
<street>Via G. Reiss Romoli, 274</street>
<city>Turin</city>
<code>10148</code>
<country>Italy</country>
</postal>
<email>enrico.marocco@telecomitalia.it</email>
</address>
</author>
<author initials="V." surname="Gurbani"
fullname="Vijay K. Gurbani">
<organization>Bell Laboratories, Alcatel-Lucent</organization>
<address>
<postal>
<street>1960 Lucent Lane</street>
<city>Naperville</city>
<region>IL</region>
<code>60566</code>
<country>USA</country>
</postal>
<email>vkg@alcatel-lucent.com</email>
</address>
</author>
<date month="October" year="2008"/>
<abstract>
<t>
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. This
document describes problem related to optimizing traffic
generated by peer-to-peer applications through the use of
network-layer information, provides a representative set of
use cases that may exhibit this problem, and outlines
considerations that have to be taken in account when arriving
at equitable solutions.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
A significant part of the Internet traffic today is generated by
peer-to-peer (P2P) applications used, for example, for file
sharing, realtime communications and live media streaming <xref
target="WWW.cachelogic.picture"/> <xref
target="WWW.wired.fuel"/>. Different from the client/server
architecture, P2P applications access resources (e.g. 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 arises from the fact that the
resources such systems offer are often made available through
multiple replicas. Yet 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 which, in some situations,
lead to suboptimal choices.
</t>
<t>
<list style="empty">
<t>
For example, popular metrics based on round trip time
estimation sometimes used for initial sources selection
(i.e. before actual data transmissions begin, when goodput
values are unknown) perform quite badly for file sharing
applications as they tend to ignore bandwidth and
reliability of underlying links, which have much more
influence than delay on file transfers.
</t>
</list>
</t>
<t>
Many of the existing P2P systems are based on an overlay network
consisting of direct connections peers establish among
themselves; such connections, obviously, do not account for the
underlying network topology. In addition to simply achieving
suboptimal performance, such networks can lead to congestions
and cause serious inefficiencies. As shown in <xref
target="ACM.fear"/>, traffic generated by popular P2P
applications often cross network boundaries multiple times,
overloading links which are frequently subject to congestion
<xref target="ACM.bottleneck"/>.
</t>
<t>
Recent studies <xref target="ACM.ispp2p"/> <xref
target="WWW.p4p.overview"/> <xref target="ACM.ono"/> have shown
that if Internet Service Providers (ISP), network operators or
third parties in general provide reliable network information
such as topology and/or bandwidth to P2P applications, it would
be possible to greatly increase application performance, reduce
congestion and optimize the overall traffic across different
networks. This document gives the problem statement of
optimizing traffic generated by P2P applications using
information provided by a separate party.
</t>
<t>
The rest of this document is structured as follows. <xref
target="problem"/> introduces the problem more formally. <xref
target="usecases"/> describes some use cases where both P2P
applications and network operators would benefit from a solution
to such a problem. <xref target="solution"/> describes the main
issues to consider when designing such a solution.
</t>
<section title="Research or Engineering?">
<t>
At the time of writing, several solutions have been proposed
to address the problem described in this document, both inside
and outside the IETF accompanied by encouraging simulation and
field test results <xref
target="I-D.bonaventure-informed-path-selection"/> <xref
target="ACM.ispp2p"/> <xref target="WWW.p4p.overview"/>. Such
solutions have been proposed independently, but all consists
of two essential parts:
<list style="symbols">
<t>
a discovery mechanism which can be used by a P2P
application to find a reliable information source;
</t>
<t>
a protocol used by P2P applications 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 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 reducing resource consumption in the
underlying network infrastructure. Applications may use the
P2P model to organize themselves, or they can be simple
client-server based, or even 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
application is based on a client-server or hybrid model,
then the usage of the terms "client" and "server" imparts
enough context for dis-ambiguity.
</t>
<t hangText="Resource:">
A piece of content (e.g. a file or a chunk of a file) or a
server process (e.g. for relaying a media stream or for
perfoming a computation) which can be accessed by
applications. In the ALTO context a resource is often
available in several equivalent replicas, shared by
different peers.
</t>
<t hangText="Resource Identifier:">
An application layer identifier used to identify a resource,
no matter how many replicas thereof 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 is needed by a resource
consumer to access the desired resource at a specific
resource provider. This information usually consists of the
resource provider's IP address, and it may include 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. This
logical structure, which can be used to implement
distributed applications, may benefit from guidance from the
ALTO service.
</t>
<t hangText="Resource Directory:">
An entity which is separate from the resource consumer, and
which assists a resource consumer to identify a set of
resource providers. In P2P applications, the resource
directory may be referred to as a P2P tracker. Some
applications do not use this concept and do the address
mapping directly in the resource consumer.
</t>
<t hangText="Host Location Attribute:">
Information which is related to the location of a host in
the network topology. The ALTO service 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. 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:">
If several resource providers are able to provide the same
resource, the ALTO service gives guidance to a resource
consumer or resource directory, on which resource
provider(s) to select, in order to optimize its performance
(or quality of experience) while minimizing resource
consumption in the underlying network infrastructure.
</t>
<t hangText="ALTO Server:">
A logical entity that provides interfaces that can be used
to query the ALTO service.
</t>
<t hangText="ALTO Client:">
The logical entity that sends ALTO queries. Depending on the
architecture of the application it may be embedded 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 Reply:">
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 reply.
</t>
<t hangText="Local Traffic:">
Internet traffic which stays within the network
infrastructure of one Internet Service Providers (ISP).
This type of traffic usually causes the least costs for the
ISP.
</t>
<t hangText="Peering Traffic:">
Internet traffic exhcanged by two Internet Service Providers
whose networks are directly connected. Apart from
infrastructure and operational costs, peering traffic is
usually free, within the contract of a peering agreement.
</t>
<t hangText="Transit Traffic:">
Internet traffic exchanged on the basis of economic
agreements between Internet Service Providers (ISP). An ISP
generally pays a transit provider for the delivery of
traffic flowing between its network and networks that are
not directly connected.
</t>
</list>
</t>
</section>
<section title="The Problem" anchor="problem">
<t>
Network engineers have been facing the problem of traffic
optimization for a long time now and have already designed
mechanisms like MPLS <xref target="RFC3031"/> and DiffServ <xref
target="RFC3260"/> to deal with it. The problem they 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 techniques and "cooperating" with external services
aware of the network topology could greatly optimize 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) generally
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 the 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 download content from. 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, reducing 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 title="Use Cases" anchor="usecases">
<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 would be 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, while 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 (i.e. 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 realtime or near-realtime way
without recurring to multicast. Such applications typically
participate in the distribution of the content, acting as both
receivers and senders; the goal of an ALTO solution would be
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 realtime communications allow users to establish direct
media flows, usually to place audio and video calls, or to
have text chats. In the basic case, media would flow directly
between the two endpoints; however, in the general case, a
significant portion of communications between users with
limited access to the Internet (e.g. users behind NATs,
firewalls or HTTP proxies) need to be relayed by other
elements. Such media relays are distributed over the Internet
-- in some cases co-located with applications with a public
address; the goal of an ALTO solution would be 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 recurring to 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 would
provide valuable information for DHT algorithms which, in
order to reduce path latency of distributed queries, include
round trip time estimations among such criteria <xref
target="SIGCOMM.resprox"/>.
</t>
</section>
</section>
<section title="Solution Considerations" anchor="solution">
<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>
ALTO services can be provided by at least three different
kinds of entity:
<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: 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: running 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 volatile 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. realtime communications
or bulk data transfer), the server will be able to indicate
priorities in its replies accomodating 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 sensible.
</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>
A common approach to optimizing traffic generated by
applications which require large data transfers is based on
caching techniques. 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 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 most popular applications (e.g. HTTP and BitTorrent).
</t>
<t>
Content awareness: since caches need to actually store the
content being delivered, they are subject to legal threats
whenever the user does not have the right to access or
distribute such content. This limitation makes caching
approaches unusable in today's popular file sharing
systems.
</t>
</list>
</t>
<t>
In general, solutions based on provision of topology
information need not to interfere with caching; to the
contrary, if ALTO service used by applications is aware of the
presence of chaches, it can point them out in its replies with
higher priorities and thus achieve greater optimization.
</t>
</section>
</section>
<section title="Security Considerations">
<t>
The approach proposed in this document requires P2P applications
to delegate a portion of their routing capability to third
parties, giving them a significant role in systems where that
would be otherwise excluded.
</t>
<t>
In the case where an ALTO solution is deployed by the network
operator, 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;
</t>
<t>
apply policies based on criteria other than network
efficiency (for example, to avoid peering points regulated
by inconvenient economic agreements).
</t>
</list>
</t>
<t>
However, 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 would not be used.
</t>
<t>
Even in cases where the ALTO service provider would decide to
maliciously alter results returned by queries only after the
solution has gained popularity (i.e. it behaves for a while to
become popular and then starts misbehaving), it would be fairly
easy for P2P application maintainers and users to revert to
solutions that are not using it. After all, it would all come
down to change some application settings in cases where the
protocol is implemented inside the client and upgrading
centralized elements for architectures like BitTorrent and
eDonkey.
</t>
</section>
<section title="Acknowledgments">
<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 initials="K." surname="Gummadi"
fullname="Krishna Gummadi">
<organization/>
</author>
<author initials="R." surname="Gummadi"
fullname="Ramakrishna Gummadi">
<organization/>
</author>
<author initials="S." surname="Ratnasamy"
fullname="Sylvia Ratnasamy">
<organization/>
</author>
<author initials="S." surname="Gribble"
fullname="Steve Gribble">
<organization/>
</author>
<author initials="S." surname="Shenker"
fullname="Scott Shenker">
<organization/>
</author>
<author initials="I." surname="Stoica"
fullname="Ion 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 initials="V." surname="Aggarwal"
fullname="Vinay Aggarwal">
<organization/>
</author>
<author initials="A." surname="Feldmann"
fullname="Anja Feldmann">
<organization/>
</author>
<author initials="C." surname="Scheideler"
fullname="Christian Scheideler">
<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 initials="T." surname="Karagiannis"
fullname="Thomas Karagiannis">
<organization/>
</author>
<author initials="P." surname="Rodriguez"
fullname="Pablo Rodriguez">
<organization/>
</author>
<author initials="K." surname="Papagiannaki"
fullname="Konstantina Papagiannaki">
<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 initials="A." surname="Akella"
fullname="Aditya Akella">
<organization/>
</author>
<author initials="S." surname="Seshan"
fullname="Srinivasan Seshan">
<organization/>
</author>
<author initials="A." surname="Shaikh"
fullname="Anees Shaikh">
<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 initials="D." surname="Choffnes"
fullname="David Choffnes">
<organization/>
</author>
<author initials="F. E." surname="Bustamante"
fullname="Fabian E. Bustamante">
<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 initials="H." surname="Xie"
fullname="Haiyong Xie">
<organization/>
</author>
<author initials="A." surname="Krishnamurthy"
fullname="Arvind Krishnamurthy">
<organization/>
</author>
<author initials="A." surname="Silberschatz"
fullname="Avi Silberschatz">
<organization/>
</author>
<author initials="R." surname="Yang"
fullname="Richard Yang">
<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 initials="A." surname="Parker"
fullname="Andrew Parker">
<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 initials="J." surname="Glasner"
fullname="Joanna Glasner">
<organization/>
</author>
<date/>
</front>
</reference>
<reference anchor="RFC3031">
<front>
<title>Multiprotocol Label Switching Architecture</title>
<author initials="E." surname="Rosen" fullname="E. Rosen">
<organization/>
</author>
<author initials="A." surname="Viswanathan"
fullname="A. Viswanathan">
<organization/>
</author>
<author initials="R." surname="Callon" fullname="R. Callon">
<organization/>
</author>
<date year="2001" month="January"/>
<abstract>
<t>
This document specifies the architecture for Multiprotocol
Label Switching (MPLS). [STANDARDS TRACK]
</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3031"/>
<format type="TXT" octets="147175"
target="ftp://ftp.isi.edu/in-notes/rfc3031.txt"/>
</reference>
<reference anchor="RFC3260">
<front>
<title>New Terminology and Clarifications for Diffserv</title>
<author initials="D." surname="Grossman"
fullname="D. Grossman">
<organization/>
</author>
<date year="2002" month="April"/>
<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 type="TXT" octets="21900"
target="ftp://ftp.isi.edu/in-notes/rfc3260.txt"/>
</reference>
<reference anchor="I-D.bonaventure-informed-path-selection">
<front>
<title>The case for an informed path selection service</title>
<author initials="D" surname="Saucez"
fullname="Damien Saucez">
<organization/>
</author>
<author initials="B" surname="Donnet"
fullname="Benoit Donnet">
<organization/>
</author>
<date month="February" day="18" 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 type="TXT"
target="http://www.ietf.org/internet-drafts/draft-bonaventure-informed-path-selection-00.txt"/>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 14:17:43 |