One document matched: draft-irtf-p2prg-mythbustering-01.xml
<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!DOCTYPE rfc SYSTEM 'rfcXXXX.dtd'>
<rfc category='info' ipr='trust200902' docName="draft-irtf-p2prg-mythbustering-01">
<?rfc toc='yes' ?>
<?rfc symrefs='yes' ?>
<?rfc sortrefs='yes'?>
<?rfc iprnotified='no' ?>
<?rfc strict='yes' ?>
<?rfc compact='yes' ?>
<front>
<title abbrev='Peer Selection in P2P Applications'>
Improving Peer Selection in Peer-to-peer Applications: Myths
vs. Reality
</title>
<author initials='E.' surname='Marocco' fullname='Enrico Marocco'>
<organization>Telecom Italia</organization>
<address>
<email>enrico.marocco@telecomitalia.it</email>
</address>
</author>
<author initials='A.' surname='Fusco' fullname='Antonio Fusco'>
<organization>Telecom Italia</organization>
<address>
<email>antonio2.fusco@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="08" month="March" year="2010"/>
<workgroup>Peer-to-peer Research Group</workgroup>
<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='RFC5693'/> is reused here;
other definitions should be consistent with it.
</t>
<section title='Seeder'>
<t>
A peer that 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 that 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 that 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 upload capacity exceeds the
download demand. A swarm in surplus mode is often referred to
as "well seeded".
</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='Myths, Facts and Discussion'>
<section title='Reduced Cross-domain Traffic'
anchor='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='RFC5632'>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>
<t>
Experiments with real BitTorrent clients and real
distributions of peers per AS run by researchers at
INRIA <xref target='LeBlond'/> have shown that ASes with
100 peers or more can save 99.5% of cross-domain traffic
with high values of locality. They have also shown that
at a global scale, i.e., 214,443 torrents, 6,1113,224
unique peers, and 9,605 ASes, high locality can save 40%
of global inter-AS traffic , i.e., 4.56 Petabytes (PB)
on 11.6 PB. This result shows that locality would be
beneficial at the scale of the Internet.
</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='Increased Application Performance'
anchor='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='RFC5632'>Comcast's P4P
trial</xref> show and increase in download rates between
13% and 85%. Interestingly, the data collected in the
experiment 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>
<t>
<xref target='LeBlond'>Experiments with real clients run
by researchers at INRIA</xref> have shown that the
measured application performance is a function of the
degree of congestion on links the locality policy tries
to reduce the traffic on. Furthermore, they have also
shown that, in the case of severe bottlenecks,
BitTorrent with locality can be more than 200% faster
than regular BitTorrent.
</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='Increased Uplink Bandwidth Usage'
anchor='bandwidth'>
<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='RFC5632'>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='Impacts on Peering Agreements'
anchor='peering'>
<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>
<t>
It's worth noting that traffic manipulation techniques have
been reportedly used by ISPs to obtain peering agreements
<xref target='Norton'/> with larger ISPs. One of the most
used technique involves injecting forged traffic into the
target ISP's network, in order to increase its transit
costs. Such a techniques aims at increasing the relevance of
the source ISP in the target's transit bill and thus
motivate the latter to sign a peering agreement. However,
traffic injection is exclusively unidirectional and easy to
detect. On the other hand, if a localization-like service
were used to direct P2P requests toward the target network,
the resulting traffic would appear fully legitimate and,
since in popular applications that follow the tit-for-tat
approach peers tend to upload to the peers they download
from, in many cases also bi-directional.
</t>
</section>
<section title='Conclusions'>
<t>
Likely.
</t>
</section>
</section>
<section title='Impacts on Transit'
anchor='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 that 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 customers 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='Swarm Weakening'
anchor='swarm'>
<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='LeBlond'>Experiments with real BitTorrent
clients 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, while <xref
target='LeBlond'/> shows that BitTorrent is extremely
robust, the level of tolerance to locality for different P2P
algorithms should be evaluated on a case-by-case basis.
</t>
</section>
<section title='Conclusions'>
<t>
Plausible, in some circumstances.
</t>
</section>
</section>
<section title='Improved P2P Caching'
anchor='caching'>
<t>
P2P caching has been proposed as a possible solution to reduce
cross-domain as well as uplink P2P traffic. Since the cache
servers ultimately act as seeders, a cache-aware localization
service would allow a seamless integration of a caching
infrastructure with P2P applications <xref
target='I-D.weaver-alto-edge-caches'/>.
</t>
<section title='Facts'>
<t>
<list style='numbers'>
<t>
<xref target='Leibowitz'>A traffic analysis performed in
a major Israeli ISP</xref> has shown that P2P traffic
has a theoretical caching potential of 67%
byte-hit-rate.
</t>
</list>
</t>
</section>
<section title='Discussion'>
<t>
P2P Caching may be beneficial for both ISPs and network
users, and locality-based optimizations may help the ISP to
direct the peers towards caches. Anyway it is hard to figure
at this point in time if the positive effects of
localization will make caching superfluous or not
economically justifiable for the ISP.
</t>
</section>
<section title='Conclusions'>
<t>
Plausible, if cost-effective for the ISP.
</t>
</section>
</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="RFC5632">
<front>
<title>
Comcast's ISP Experiences in a Proactive Network Provider
Participation for P2P (P4P) Technical Trial
</title>
<author initials="C." surname="Griffiths" fullname="C. Griffiths">
<organization/>
</author>
<author initials="J." surname="Livingood" fullname="J. Livingood">
<organization/>
</author>
<author initials="L." surname="Popkin" fullname="L. Popkin">
<organization/>
</author>
<author initials="R." surname="Woundy" fullname="R. Woundy">
<organization/>
</author>
<author initials="Y." surname="Yang" fullname="Y. Yang">
<organization/>
</author>
<date year="2009" month="September"/>
</front>
<seriesInfo name="RFC" value="5632"/>
<format type="TXT" octets="27920"
target="ftp://ftp.rfc-editor.org/in-notes/rfc5632.txt"/>
</reference>
<reference anchor='LeBlond'>
<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>
<seriesInfo name="available at" value="http://hal.inria.fr/"/>
</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>
<seriesInfo name="in" value="ACM SIGCOMM Computer Communication Review, vol. 38, no. 4"/>
</reference>
<reference anchor="Aggarwal">
<front>
<title>
Can ISPs and P2P systems co-operate for improved performance?
</title>
<author initials="V." surname="Aggarwal">
<organization/>
</author>
<author initials="A." surname="Feldmann">
<organization/>
</author>
<author initials="C." surname="Scheidler">
<organization/>
</author>
</front>
<seriesInfo name="in"
value="ACM SIGCOMM Computer Communications Review, vol. 37, no. 3"/>
</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: Explicit Communications for Cooperative Control Between P2P and Network Providers
</title>
<author initials="H." surname="Xie">
<organization/>
</author>
<author initials="Y. R." surname="Yang">
<organization/>
</author>
<author initials="A." surname="Krishnamurthy">
<organization/>
</author>
<author initials="Y. G." surname="Liu">
<organization/>
</author>
<author initials="A." surname="Silberschatz">
<organization/>
</author>
</front>
<seriesInfo name="in" value="ACM SIGCOMM Computer Communication Review, vol. 38, no. 4"/>
</reference>
<reference anchor='Norton'>
<front>
<title>
The art of Peering: The peering playbook
</title>
<author initials='W' surname='Norton'>
<organization/>
</author>
</front>
<seriesInfo name="available from" value="http://d.drpeering.net/"/>
</reference>
<reference anchor='Leibowitz'>
<front>
<title>
Are file swapping networks cacheable? Characterizing p2p
traffic
</title>
<author initials='N' surname='Leibowitz'>
<organization/>
</author>
<author initials='A' surname='Bergman'>
<organization/>
</author>
<author initials='R' surname='Ben-Shaul'>
<organization/>
</author>
<author initials='A' surname='Shavit'>
<organization/>
</author>
</front>
<seriesInfo name="in" value="proceedings of the 7th Int. WWW Caching Workshop"/>
</reference>
<reference anchor="RFC5693">
<front>
<title>
Application-Layer Traffic Optimization (ALTO) Problem Statement
</title>
<author initials="J." surname="Seedorf" fullname="J. Seedorf">
<organization/>
</author>
<author initials="E." surname="Burger" fullname="E. Burger">
<organization/>
</author>
<date year="2009" month="October"/>
</front>
<seriesInfo name="RFC" value="5693"/>
<format type="TXT" octets="34234"
target="ftp://ftp.rfc-editor.org/in-notes/rfc5693.txt"/>
</reference>
<reference anchor='I-D.weaver-alto-edge-caches'>
<front>
<title>
Peer to Peer Localization Services and Edge Caches
</title>
<author initials='N' surname='Weaver' fullname='Nicholas Weaver'>
<organization />
</author>
<date month='March' day='4' year='2009' />
</front>
<seriesInfo name='Internet-Draft'
value='draft-weaver-alto-edge-caches-00' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-weaver-alto-edge-caches-00.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'>
<front>
<title>
Peering Dispute With AOL Slows Cogent Customer Access
</title>
<author initials='Y' surname='Noguchi' fullname='Yuki Noguchi'>
<organization />
</author>
</front>
<seriesInfo name="appeared on" value="Washington Post, December 17, 2002"/>
</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 initials='M' surname='Ricknas' fullname='Mikael Ricknas'>
<organization />
</author>
</front>
<seriesInfo name="appeared on" value="PCWorld, October 31, 2008"/>
</reference>
</references>
<section title='Myths/References/Facts Matrix'>
<texttable>
<ttcol></ttcol>
<ttcol>[Xie]</ttcol>
<ttcol>[RFC5632]</ttcol>
<ttcol>[Aggarwal]</ttcol>
<ttcol>[LeBlond]</ttcol>
<c>Cross-domain Traffic (<xref target='traffic'/>)</c>
<c>X</c>
<c>X</c>
<c>X</c>
<c>X</c>
<c>Application Performance (<xref target='performance'/>)</c>
<c>X</c>
<c>X</c>
<c>X</c>
<c>X</c>
<c>Uplink Bandwidth (<xref target='bandwidth'/>)</c>
<c></c>
<c>X</c>
<c></c>
<c></c>
<c>Impacts on Peering (<xref target='peering'/>)</c>
<c></c>
<c></c>
<c></c>
<c></c>
<c>Impacts on Transit (<xref target='transit'/>)</c>
<c></c>
<c></c>
<c></c>
<c></c>
<c>Swarm Weakening (<xref target='swarm'/>)</c>
<c></c>
<c></c>
<c></c>
<c>X</c>
<c>Improved P2P Caching (<xref target='caching'/>)</c>
<c></c>
<c></c>
<c></c>
<c></c>
</texttable>
<texttable>
<ttcol></ttcol>
<ttcol>[Choffnes]</ttcol>
<ttcol>[Seetharaman]</ttcol>
<ttcol>[Leibowitz]</ttcol>
<c>Cross-domain Traffic (<xref target='traffic'/>)</c>
<c></c>
<c></c>
<c></c>
<c>Application Performance (<xref target='performance'/>)</c>
<c>X</c>
<c>X</c>
<c>X</c>
<c>Uplink Bandwidth (<xref target='bandwidth'/>)</c>
<c></c>
<c></c>
<c></c>
<c>Impacts on Peering (<xref target='peering'/>)</c>
<c></c>
<c></c>
<c></c>
<c>Impacts on Transit (<xref target='transit'/>)</c>
<c></c>
<c></c>
<c></c>
<c>Swarm Weakening (<xref target='swarm'/>)</c>
<c></c>
<c>X</c>
<c></c>
<c>Improved P2P Caching (<xref target='caching'/>)</c>
<c></c>
<c></c>
<c>X</c>
</texttable>
</section>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-22 22:48:17 |