One document matched: draft-marocco-p2prg-mythbustering-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfcXXXX.dtd">
<rfc docName="draft-marocco-p2prg-mythbustering-00" category="info" ipr="trust200902">
<?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="Mythbustering P2P Traffic Localization">
Mythbustering Peer-to-peer Traffic Localization
</title>
<author initials="E." surname="Marocco" fullname="Enrico Marocco">
<organization>Telecom Italia</organization>
<address>
<email>enrico.marocco@telecomitalia.it</email>
</address>
</author>
<author initials="I." surname="Rimac" fullname="Ivica Rimac">
<organization>Bell Labs, Alcatel-Lucent</organization>
<address>
<email>rimac@bell-labs.com</email>
</address>
</author>
<author initials="V." surname="Gurbani"
fullname="Vijay K. Gurbani">
<organization>Bell Labs, Alcatel-Lucent</organization>
<address>
<email>vkg@alcatel-lucent.com</email>
</address>
</author>
<date day="26" month="February" year="2009"/>
<abstract>
<t>
Peer-to-peer traffic optimization techniques that aim at
improving locality in the peer selection process have attracted
great interest in the research community and have been subject
of much discussion. Some of this discussion has produced
controversial myths, some rooted in reality while others remain
unfounded. This document evaluates the most prominent myths
attributed to P2P optimization techniques by referencing the
most relevant study (or studies) that have addressed facts
pertaining to the myth. Using these studies, we hope to either
confirm or refute each specific myth.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
Peer-to-peer (P2P) applications used for file-sharing, streaming
and realtime communications exchange large amounts of data in
connections established among the peers themselves and are
responsible for an important part of the Internet traffic.
Since applications have generally no knowledge of the underlying
network topology, the traffic they generate is frequent cause of
congestions in inter-domain links and significantly contributes
to the raising of transit costs paid by network operators and
Internet Service Providers (ISP).
</t>
<t>
One approach to reduce congestions and transit costs caused by
P2P applications consists of enhancing the peer selection
process with the introduction of proximity information. This
allows the peers to identify the topologically closer resource
among all the instances of the resources they are looking for.
Several solutions following such an approach have recently been
proposed <xref target="Choffnes"/> <xref target="Aggarwal"/>
<xref target="Xie"/>, some of which are now being considered for
standardization in the IETF <xref target="ALTO"/>.
</t>
<t>
Despite extensive research based on simulations and field
trials, it is hard to predict how proposed solutions would
perform in a real-world systems made of millions of peers. For
this reason, possible effects and side-effects of optimization
techniques based on P2P traffic localization have been a matter
of frequent debate. This document describes some of the most
interesting effects, referencing relevant studies which have
addressed them and trying to determine whether and in what
measure they are likely to happen.
</t>
<t>
Each possible effect -- or Myth -- is examined in three phases:
<list style="symbols">
<t>
Facts: in which a list of relevant data is presented,
usually collected from simulations or field trials;
</t>
<t>
Discussion: in which the reasons for and against the myth
are discussed based on the facts previously listed;
</t>
<t>
Conclusions: in which the authors try to epress a reasonable
measure of the plausibility of the myth.
</t>
</list>
</t>
<t>
This document at the current stage is little more than a
strawman. With the help of the IRTF community, the authors
would like to improve it, in the number of the Facts, in the
quality of the Discussion and, particularly, in the
trustworthiness of the Conclusions.
</t>
</section>
<section title="Definitions">
<t>
Terminology defined in <xref
target="I-D.marocco-alto-problem-statement"/> is reused here;
other definitions should be consistent with it.
</t>
<section title="Seeder">
<t>
A peer which has a complete copy of the content it is sharing,
and still offers it for upload. The term "seeder" is adopted
from BitTorrent terminology and is used in this document to
indicate upload-only peers also in other kinds of P2P
applications.
</t>
</section>
<section title="Leecher">
<t>
A peer which has not yet completed the download of a specific
content (but usually has already started offering for upload
the part it is in possession of). The term "leecher" is
adopted from BitTorrent terminology and is used in this
document to indicate peers which are both uploading and
downloading, also in other kinds of P2P applications.
</t>
</section>
<section title="Swarm">
<t>
The group of peers that are uploading and/or downloading
pieces of the same content. The term "swarm" is commonly used
in BitTorrent, to indicate all seeders and leechers exchanging
chuncks of a particular file; however, in this document it is
used more generally, for example, in the case of P2P streaming
applications, to refer to all peers receiving and/or
transmitting the same media stream.
</t>
</section>
<section title="Tit-for-tat">
<t>
A content exchange strategy where the amount of data sent by a
leecher to another leecher is roughly equal to the amount of
data received from it. P2P applications, most notably
BitTorrent, adopt such an approach to maximize resources
shared by the users.
</t>
</section>
<section title="Surplus Mode">
<t>
The status of a swarm where the number of seeders is
significantly greater than the number of leechers (i.e. the
total download demand is abundantly satisfied by the upload
capacity).
</t>
</section>
<section title="Transit">
<t>
The service through which a network can exchange IP packets
with all other networks it is not directly connected to. The
transit service is always regulated by a contract, according
to which the custumer (i.e. a network operator or an ISP) pays
the transit provider per amount of data exchanged.
</t>
</section>
<section title="Peering">
<t>
The direct interconnection between two separate networks for
the purpose of exchanging traffic without recurring to a
transit provider. Peering is usually regulated by agreements
taking in account the amount of traffic generated by each
party in each direction.
</t>
</section>
<!--
<section title="Backhaul">
<t>
The links connecting the backbone (i.e. the core) to the edges
of a network (e.g. DSLAMs, CMTSs, or wireless base stations).
</t>
</section>
-->
</section>
<section title="Myth: Reduced Cross-domain Traffic">
<t>
The reduction in cross-domain traffic (and thus in transit costs
due to it) is one of the positive effects P2P traffic
localization techniques are expected to cause, and also the main
reason way ISPs look at them with interest. Simulations and
field tests have shown a reduction varying from 20% to 80%.
</t>
<section title="Facts">
<t>
<list style="numbers">
<t>
Various simulations and initial field trials of the <xref
target="Xie">P4P solution</xref> on average show a 70%
reduction of cross-domain traffic.
</t>
<t>
Data observed in <xref
target="I-D.livingood-woundy-p4p-experiences">Comcast's
P4P trial</xref> show a 34% reduction of the outgoing P2P
traffic and an 80% reduction of the incoming.
</t>
<t>
Simulations of the <xref target="Aggarwal">"oracle-based"
approach</xref> proposed by researchers at TU Berlin show
an increase in local exchanges from 10% in the unbiased
case to 60%-80% in the localized case.
</t>
</list>
</t>
</section>
<section title="Discussion">
<t>
Tautologically, P2P traffic localization techniques tend to
localize content exchanges, and thus reduce cross-domain
traffic.
</t>
</section>
<section title="Conclusions">
<t>
Confirmed.
</t>
</section>
</section>
<section title="Myth: Increased Application Performance">
<t>
Ostensibly, the increase in application performance is the main
reason for the consideration of P2P traffic localization
techniques in academia and industry. The expected increase
depends on the specific application: file sharing applications
witness an increase in the download rate, realtime communication
applications observe lower delay and jitter, and streaming
applications can benefit by a high constant bitrate.
</t>
<section title="Facts">
<t>
<list style="numbers">
<t>
Various simulations and initial field trials of the <xref
target="Xie">P4P solution</xref> show an average reduction
of download completion times between 10% and 23%.
</t>
<t>
Data observed in <xref
target="I-D.livingood-woundy-p4p-experiences">Comcast's
P4P trial</xref> show and increase in download rates
between 13% and 85%. Interestingly, the collected data
also indicate that fine-grained localization is less
effective in improving download performance compared
to lower levels of localization.
</t>
<t>
Data collected in the <xref target="Choffnes">Ono
experiment</xref> show a 31% average download rate
improvement.
<list style="symbols">
<t>
In networks where the ISP provides higher bandwidth
for in-network traffic (e.g. as in the case of RDSNET,
described in <xref target="Choffnes"/>), the increase
is significantly higher.
</t>
<t>
In networks with relatively low uplink bandwidth (as
the case of Easynet, described in <xref
target="Choffnes"/>), traffic localization slightly
degrades application performance.
</t>
</list>
</t>
<t>
Simulations of the <xref target="Aggarwal">"oracle-based"
approach</xref> proposed by researchers at TU Berlin show
a reduction in download times between 16% and 34%.
</t>
<t>
<xref target="Seetharaman">Simulations by Bell Labs</xref>
indicate that localization is not as effective in all
scenarios and that the user experience can suffer in
certain locality-aware swarms based on the actual
implementation of locality.
</t>
</list>
</t>
</section>
<section title="Discussion">
<t>
It seems that traffic localization techniques often cause an
improvement in application performance. However, it must be
noted that such beneficial effects heavily depend on the
network infrastructures. In some cases, for example in
networks with relatively low uplink bandwidth, localization
seems to be useless if not harmful. Also, beneficial effects
depend on the swarm size; imposing locality when only a small
set of local peers are available may even decrease download
performance for local peers.
</t>
</section>
<section title="Conclusions">
<t>
Very likely, especially for large swarms and in networks with
high capacity.
</t>
</section>
</section>
<section title="Myth: Increased Uplink Bandwidth Usage">
<t>
The increase in uplink bandwidth usage would be a negative
effect, especially in environments where the access network is
based on technologies providing asymmetric upstream/downstream
bandwidth (e.g. DSL or DOCSIS).
</t>
<section title="Facts">
<t>
<list style="numbers">
<t>
Data observed in <xref
target="I-D.livingood-woundy-p4p-experiences">Comcast's
P4P trial</xref> show no increase in the uplink traffic.
</t>
</list>
</t>
</section>
<section title="Discussion">
<t>
Mathematically, average uplink traffic remains the same as
long as the swarm is not in surplus mode. However, in some
particular cases where surplus capacity is available,
localization may lead to local low-bandwiwth leechers
connecting to each other instead of trying the external
seeders. Even if such a phenomenon has not been observed in
simulations and field trials, it could occur to applications
that use localization as the only means for optimization when
some content becomes popular in different areas at different
times (as is the case of prime time TV shows distributed on
BitTorrent networks minutes after getting aired in North
America).
</t>
</section>
<section title="Conclusions">
<t>
Unlikely.
</t>
</section>
</section>
<section title="Myth: Impacts on Peering Agreements">
<t>
Peering agreements are usually established on a reciprocity
basis, assuming that the amount of data sent and received by
each party is roughly the same (or, in case of asymmetric
traffic volumes, a compensation fee is paid by the party which
would otherwise obtain the most gain). P2P traffic localization
techniques aim at reducing cross-domain traffic and thus might
also impact peering agreements.
</t>
<section title="Facts">
<t>
No significant publications, simulations or trials have tried
to understand how traffic localization techniques can
influence factors that rule how peering agreements are
established and maintained.
</t>
</section>
<section title="Discussion">
<t>
This is a key topic for network operators and ISPs, and
certainly deserves to be analyzed more accurately. Some random
thoughts follow.
</t>
<t>
It seems reasonable to expect different effects depending on
the kinds of agreements. For example:
<list style="symbols">
<t>
ISPs with different customer bases: the ISP whose
customers generate more P2P traffic can achieve a greater
reduction of cross-domain traffic and thus could probably
be in a position to re-negotiate the contract ruling the
peering agreement;
</t>
<t>
ISPs with similar customer bases:
<list style="symbols">
<t>
ISPs with different access technologies: customers of
the ISP which provides higher bandwidth -- and, in
particular, higher uplink bandwidth -- will have more
incentives for keeping their P2P traffic
local. Consequently, the ISP with a better
infrastructure will be able to achieve a greater
reduction in cross-domain traffic and will be probably
in a position to re-negotiate the peering agreement;
</t>
<t>
ISPs with similar access technologies: both ISPs would
achieve roughly the same reduction in cross-domain
traffic and thus the conditions under which the
peering agreement had been established would not
change much.
</t>
</list>
</t>
</list>
</t>
<t>
As a consequence of the reasoning above, it seems reasonable
to expect that the simple fact that one ISP starts localizing
its P2P traffic will be a strong incentive for the ISPs it
peers with to do that as well.
</t>
</section>
<section title="Conclusions">
<t>
Likely.
</t>
</section>
</section>
<section title="Myth: Impacts on Transit">
<t>
One of the main goals of P2P traffic localization techniques is
to allow ISPs to keep local a part of the traffic generated by
their customers and thus save on transit costs. However, similar
techniques based on de-localization rather than localization may
be used by those ISP which are also transit providers to
artificially increase the amount of data exchanged with networks
they provide transit to (i.e. pushing the peers run by their
custormers to establish connections with peers in the networks
that pay them for transit).
</t>
<section title="Facts">
<t>
No significant publications, simulations or trials have tried
to study effects of traffic localization techniques on the
dynamics of transit provision economics.
</t>
</section>
<section title="Discussion">
<t>
It is actually very hard to predict how the economics of
transit provision would be affected by the tricks some transit
providers could play on their customers making use of P2P
traffic localization -- or, in this particular case,
de-localization -- techniques. This is also a key topic for
ISPs, definitely worth an accurate investigation.
</t>
<t>
Probably, the only lesson contentions concerning transit and
peering agreement have teached so far <xref
target="CogentVsAOL"/> <xref target="SprintVsCogent"/> is
that, at the end of the day, no economic factor, no matter how
much relevant it is, is able to isolate different networks
from each other.
</t>
</section>
<section title="Conclusions">
<t>
Likely.
</t>
</section>
</section>
<section title="Myth: Swarm Weakening">
<t>
Peer selection techniques based on locality information are
certainly beneficial in areas where the density of peers is high
enough, but may cause damages otherwise. Some studies have tried
to understand to what extent locality can be pushed without
damaging peers in isolated parts of the network.
</t>
<section title="Facts">
<t>
<list style="numbers">
<t>
<xref target="Le Blond">Simulations run by researchers at
INRIA</xref> have shown that, in BitTorrent, even when
peer selection is heavily based on locality, swarms do not
get damaged.
</t>
<t>
<xref target="Seetharaman">Simulations by Bell Labs</xref>
indicate that the user experience can suffer in certain
locality-aware swarms based on the actual implementation
of locality.
</t>
</list>
</t>
</section>
<section title="Discussion">
<t>
It seems reasonable to expect that excessive traffic
localization will cause some degree of deterioration in P2P
swarms based on the tit-for-tat approach, and the damages of
such deterioration will likely affect most users in networks
with lower density of peers. However, as shown in <xref
target="Le Blond"/>, the right balance of randomness and
locality depends on the P2P algorithm.
</t>
<t>
On the other hand, P2P systems not adopting the tit-for-tat
approach (e.g. the eDonkey network) should not be damaged by
locality-based optimizations.
</t>
</section>
<section title="Conclusions">
<t>
Plausible, in some circustancies.
</t>
</section>
</section>
<section title="Security Considerations">
<t>
No considerations at this time.
</t>
</section>
<section title="Acknowledgments">
<t>
This documents tries to summarize discussions happened in live
meetings and on several mailing lists: all those who are reading
this have probably contributed more ideas and more material than
the authors themselves.
</t>
</section>
</middle>
<back>
<references title="Informative References">
<reference anchor="I-D.livingood-woundy-p4p-experiences">
<front>
<title>
Comcast's ISP Experiences In a Recent P4P Technical Trial
</title>
<author initials="C" surname="Griffiths"
fullname="Chris Griffiths">
<organization/>
</author>
<author initials="J" surname="Livingood"
fullname="Jason Livingood">
<organization/>
</author>
<author initials="R" surname="Woundy"
fullname="Richard Woundy">
<organization/>
</author>
<date month="October" day="28" year="2008"/>
</front>
<seriesInfo name="Internet-Draft"
value="draft-livingood-woundy-p4p-experiences-02"/>
<format type="TXT"
target="http://www.ietf.org/internet-drafts/draft-livingood-woundy-p4p-experiences-02.txt"/>
</reference>
<reference anchor="Le Blond">
<front>
<title>
Pushing BitTorrent Locality to the Limit
</title>
<author initials="S" surname="Le Blond">
<organization/>
</author>
<author initials="A" surname="Legout">
<organization/>
</author>
<author initials="W" surname="Dabbous">
<organization/>
</author>
</front>
</reference>
<reference anchor="Choffnes">
<front>
<title>
Taming the Torrent: A practical approach to reducing
cross-ISP traffic in P2P systems
</title>
<author initials="D" surname="Choffnes">
<organization/>
</author>
<author initials="F" surname="Bustamante">
<organization/>
</author>
</front>
</reference>
<reference anchor="Aggarwal">
<front>
<title>
Improving User and ISP Experience through ISP-aided P2P
Localityraffic in P2P systems
</title>
<author initials="V" surname="Aggarwal">
<organization/>
</author>
<author initials="O" surname="Akonjang">
<organization/>
</author>
<author initials="A" surname="Feldmann">
<organization/>
</author>
</front>
</reference>
<reference anchor="Seetharaman">
<front>
<title>
Applicability and Limitations of Locality-Awareness in
BitTorrent File-Sharing
</title>
<author initials="S" surname="Seetharaman">
<organization/>
</author>
<author initials="V" surname="Hilt">
<organization/>
</author>
<author initials="I" surname="Rimac">
<organization/>
</author>
<author initials="M" surname="Ammar">
<organization/>
</author>
</front>
</reference>
<reference anchor="Xie">
<front>
<title>
P4P: Provider Portal for Applications
</title>
<author initials="H" surname="Xie">
<organization/>
</author>
<author initials="Y" surname="Yang">
<organization/>
</author>
<author initials="A" surname="Krishnamurthy">
<organization/>
</author>
<author initials="Y" surname="Liu">
<organization/>
</author>
<author initials="A" surname="Silberschatz">
<organization/>
</author>
</front>
</reference>
<reference anchor="I-D.marocco-alto-problem-statement">
<front>
<title>
Application-Layer Traffic Optimization (ALTO) Problem Statement
</title>
<author initials="J" surname="Seedorf"
fullname="Jan Seedorf">
<organization/>
</author>
<author initials="E" surname="Burger"
fullname="Vijay Gurbani">
<organization/>
</author>
<date month="February" day="5" year="2009"/>
</front>
<seriesInfo name="Internet-Draft"
value="draft-marocco-alto-problem-statement-04"/>
<format type="TXT"
target="http://www.ietf.org/internet-drafts/draft-marocco-alto-problem-statement-04.txt"/>
</reference>
<reference anchor="ALTO"
target="http://ietf.org/html.charters/alto-charter.html">
<front>
<title>
Application-Layer Traffic Optimization (ALTO) Working Group
</title>
<author initials="" surname="">
<organization/>
</author>
</front>
</reference>
<reference anchor="CogentVsAOL"
target="http://legalminds.lp.findlaw.com/list/cyberia-l/msg42080.html">
<front>
<title>
Peering Dispute With AOL Slows Cogent Customer Access
</title>
<author surname="Washington Post">
<organization/>
</author>
</front>
</reference>
<reference anchor="SprintVsCogent"
target="http://www.pcworld.com/businesscenter/article/153123/sprintcogent_dispute_puts_small_rip_in_fabric_of_internet.html">
<front>
<title>
Sprint-Cogent Dispute Puts Small Rip in Fabric of Internet
</title>
<author surname="PC World">
<organization/>
</author>
</front>
</reference>
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-24 04:11:03 |