Peer-to-peer
Internet Research Group Task Force (IRTF)                           E. Marocco
Internet-Draft
Request for Comments: 6821                                      A. Fusco
Intended status:
Category: Informational                                   Telecom Italia
Expires: March 24, 2013
ISSN: 2070-1721                                                 I. Rimac
                                                              V. Gurbani
                                               Bell Labs, Alcatel-Lucent
                                                      September 20,
                                                           December 2012

         Improving Peer Selection in Peer-to-peer Peer-to-Peer Applications:
                           Myths vs. Reality
                   draft-irtf-p2prg-mythbustering-03

Abstract

   Peer-to-peer (P2P) traffic optimization techniques that aim at
   improving locality in the peer selection process have attracted great
   interest in the research community and have been the 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) or
   studies that have addressed facts pertaining to the myth.  Using
   these studies, we the authors hope to either confirm or refute each
   specific myth.

   This document is a product of the IRTF P2PRG (peer-to-peer research
   group). (Peer-to-Peer Research
   Group).

Status of this This Memo

   This Internet-Draft document is submitted in full conformance with not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the
   provisions Internet Research Task Force
   (IRTF).  The IRTF publishes the results of BCP 78 Internet-related research
   and BCP 79.

   Internet-Drafts are working documents development activities.  These results might not be suitable for
   deployment.  This RFC represents the consensus of the Peer-to-peer
   Research Group Research Group of the Internet Engineering Research Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid
   (IRTF).  Documents approved for publication by the IRSG are not a maximum
   candidate for any level of Internet Standard; see Section 2 of RFC
   5741.

   Information about the current status of six months this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on March 24, 2013.
   http://www.rfc-editor.org/info/rfc6821.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4 ....................................................4
   2. Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  5
     2.1.  Seeder . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     2.2.  Leecher  . . . . . . . . . . . . . . . . . . . . . . . . .  5
     2.3.  Swarm  . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     2.4.  Tit-for-tat  . . . . . . . . . . . . . . . . . . . . . . .  5
     2.5.  Surplus Mode . . . . . . . . . . . . . . . . . . . . . . .  6
     2.6.  Transit  . . . . . . . . . . . . . . . . . . . . . . . . .  6
     2.7.  Peering  . . . . . . . . . . . . . . . . . . . . . . . . .  6 .....................................................5
   3. Myths, Facts Facts, and Discussion  . . . . . . . . . . . . . . . . .  6 ....................................6
      3.1. Reduced Cross-domain Cross-Domain Traffic . . . . . . . . . . . . . . .  6 ...............................6
           3.1.1. Facts  . . . . . . . . . . . . . . . . . . . . . . . .  6 ...............................................6
           3.1.2. Discussion . . . . . . . . . . . . . . . . . . . . . .  7 ..........................................7
           3.1.3. Conclusions  . . . . . . . . . . . . . . . . . . . . .  7 .........................................7
      3.2. Increased Application Performance  . . . . . . . . . . . .  7 ..........................7
           3.2.1. Facts  . . . . . . . . . . . . . . . . . . . . . . . .  7 ...............................................7
           3.2.2. Discussion . . . . . . . . . . . . . . . . . . . . . .  8 ..........................................8
           3.2.3. Conclusions  . . . . . . . . . . . . . . . . . . . . .  8 .........................................9
      3.3. Increased Uplink Bandwidth Usage . . . . . . . . . . . . .  8 ...........................9
           3.3.1. Facts  . . . . . . . . . . . . . . . . . . . . . . . .  8 ...............................................9
           3.3.2. Discussion . . . . . . . . . . . . . . . . . . . . . .  8 ..........................................9
           3.3.3. Conclusions  . . . . . . . . . . . . . . . . . . . . .  9 .........................................9
      3.4. Impacts on Peering Agreements  . . . . . . . . . . . . . .  9 ..............................9
           3.4.1. Facts  . . . . . . . . . . . . . . . . . . . . . . . .  9 ..............................................10
           3.4.2. Discussion . . . . . . . . . . . . . . . . . . . . . .  9 .........................................10
           3.4.3. Conclusions  . . . . . . . . . . . . . . . . . . . . . 10 ........................................11
      3.5. Impacts on Transit . . . . . . . . . . . . . . . . . . . . 10 ........................................11
           3.5.1. Facts  . . . . . . . . . . . . . . . . . . . . . . . . 10 ..............................................11
           3.5.2. Discussion . . . . . . . . . . . . . . . . . . . . . . 10 .........................................11
           3.5.3. Conclusions  . . . . . . . . . . . . . . . . . . . . . 11 ........................................11
      3.6. Swarm Weakening  . . . . . . . . . . . . . . . . . . . . . 11 ...........................................12
           3.6.1. Facts  . . . . . . . . . . . . . . . . . . . . . . . . 11 ..............................................12
           3.6.2. Discussion . . . . . . . . . . . . . . . . . . . . . . 11 .........................................12
           3.6.3. Conclusions  . . . . . . . . . . . . . . . . . . . . . 11 ........................................12
      3.7. Improved P2P Caching . . . . . . . . . . . . . . . . . . . 11 ......................................12
           3.7.1. Facts  . . . . . . . . . . . . . . . . . . . . . . . . 12 ..............................................12
           3.7.2. Discussion . . . . . . . . . . . . . . . . . . . . . . 12 .........................................13
           3.7.3. Conclusions  . . . . . . . . . . . . . . . . . . . . . 12 ........................................13
   4. Security Considerations  . . . . . . . . . . . . . . . . . . . 12 ........................................13
   5. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 12 ................................................13
   6. Informative References . . . . . . . . . . . . . . . . . . . . 12 .........................................13
   Appendix A. Myths/References/Facts Matrix . . . . . . . . . . . . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 .........................14

1.  Introduction

   Peer-to-peer (P2P) applications used for file-sharing, streaming streaming, and
   realtime
   real-time 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 inter-domain links and significantly contributes to the raising of
   transit costs paid by network operators and Internet Service
   Providers (ISP). (ISPs).

   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. searching through.  Several solutions
   following such an approach have recently been proposed [Choffnes]
   [Aggarwal] [Xie], some of which are now being considered for
   standardization in the IETF [ALTO].  While this document serves to
   inform the protocol work going on in the IETF ALTO working group,
   this document does not specify a protocol of any kind, nor is this
   document a product of the IETF.

   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 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 that have addressed them and trying to determine
   whether and in what measure they are likely to happen.

   Each possible effect -- or Myth myth -- is examined in three phases:

   o  Facts: in which a list of relevant data is presented, usually
      collected from simulations or field trials;

   o  Discussion: in which the reasons for supporting and against opposing the myth
      are discussed based on the facts previously listed;

   o  Conclusions: in which the authors try to epress express a reasonable
      measure of the plausibility of the myth.

      Note: Even though a myth is an unfounded or false notion, we have
      nonetheless chosen to provocatively assign a confirmation
      likelihood to each of the myths in Section 3.  This is a
      whimsical, but we believe effective, attempt that was inspired by
      the TV show "Mythbusters", wherein each myth was "busted", deemed
      "plausible", or "confirmed" by the end of the show.

   This document represents the consensus of the P2PRG.  The first
   version of this draft document appeared in February 2009 2009, and there was a
   sizeable discussion on the contents of the document thereafter.  The
   draft
   document has been improved by incorporating comments from experts in
   the area of peer-to-peer networks as well as casual, but informed informed,
   users of such networks.  The IRTF community has helped improve the
   number of facts, facts and quality of discussion and enhanced the
   trustworthiness of the conclusions documented.

   This document essentially represents the view of the participating
   P2PRG IRTF community between 2009 and the latter part of 2010; as
   such, it is like a snapshot: frozen snapshot in time.  While some aspects are
   confirmed with references to pertinent literature, other aspects
   reflect the state of discussions in the RG at the time of writing and
   may require further investigation beyond the publication date of this
   document.

2.  Definitions

   Terminology defined in [RFC5693] is reused here; other definitions
   should be consistent with it.

2.1.  Seeder the terminology in that document.

   Seeder:

      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 that are also in other kinds of P2P
      applications.

2.2.  Leecher

   Leecher:

      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 downloading and are used in
      other kinds of P2P applications.

2.3.  Swarm

   Swarm:

      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 chunks
      of a particular file; however, in this document document, it is used more generally,
   for example,
      generally (e.g., in the case of P2P streaming applications, applications) to
      refer to all peers receiving and/or transmitting the same media
      stream.

2.4.  Tit-for-tat

   Tit-for-Tat:

      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.

2.5.

   Surplus Mode Mode:

      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".

2.6.  Transit

   Transit:

      The service through which a network can exchange IP packets with
      all other networks to which it is not directly connected to. connected.  The
      transit service is always regulated by a contract, according to
      which the custumer
   (i.e. customer (i.e., a network operator or an ISP) pays the
      transit provider per amount of data exchanged.

2.7.  Peering

   Peering:

      The direct interconnection between two separate networks for the
      purpose of exchanging traffic without recurring to requiring a transit
      provider.  Peering is usually regulated by agreements taking in
      account the amount of traffic generated by each party in each
      direction.

3.  Myths, Facts Facts, and Discussion

3.1.  Reduced Cross-domain Cross-Domain Traffic

   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 why ISPs
   look at them with interest.  Simulations and field tests have shown a
   reduction varying from 20% to 80%.

3.1.1.  Facts

   1.  Various simulations and initial field trials of the P4P solution
       [Xie] on average show a 70% reduction of cross-domain traffic.

   2.  Data observed in Comcast's P4P trial [RFC5632] show a 34%
       reduction of the outgoing P2P traffic and an 80% reduction of the
       incoming.

   3.  Simulations of the "oracle-based" approach [Aggarwal] proposed by
       researchers at TU Technischen Universitat Berlin (TU Berlin) show an
       increase in local exchanges from 10% in the unbiased case to
       60%-80% in the localized case.

   4.  Experiments with real BitTorrent clients and real distributions
       of peers per AS Autonomous System (AS) run by researchers at INRIA
       [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 on 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 , 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.

3.1.2.  Discussion

   Tautologically, P2P traffic localization techniques tend to localize
   content exchanges, and thus reduce cross-domain traffic.

3.1.3.  Conclusions

   Confirmed.

3.2.  Increased Application Performance

   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 file-sharing applications witness an increase
   in the download rate, realtime real-time communication applications observe
   lower delay and jitter, and streaming applications can benefit by a
   high constant bitrate.

3.2.1.  Facts

   1.  Various simulations and initial field trials of the P4P solution
       [Xie] show an average reduction of download completion times
       between 10% and 23%.

   2.  Data observed in Comcast's P4P trial [RFC5632] show and an 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.

   3.  Data collected in the Ono experiment [Choffnes] show a 31%
       average download rate improvement.

       *  In networks where the ISP provides higher bandwidth for in-
          network traffic (e.g. (e.g., as in the case of RDSNET, a Romanian ISP
          (RDSNET), described in [Choffnes]), the increase is
          significantly higher.

       *  In networks with relatively low uplink bandwidth (as the case
          of Easynet, described in [Choffnes]), traffic localization
          slightly degrades application performance.

   4.  Simulations of the "oracle-based" approach [Aggarwal] proposed by
       researchers at TU Berlin show a reduction in download times
       between 16% and 34%.

   5.  Simulations by Bell Labs [Seetharaman] 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.

   6.  Experiments with real clients run by researchers at INRIA
       [LeBlond] have shown that the measured application performance is
       a function of the degree of congestion on links on which the
       locality policy tries to reduce the traffic on. traffic.  Furthermore, they
       have also shown that, in the case of severe bottlenecks,
       BitTorrent with locality can be more than 200% faster than
       regular BitTorrent.

3.2.2.  Discussion

   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 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 is available
   may even decrease download performance for local peers.

3.2.3.  Conclusions

   Very likely, especially for large swarms and in networks with high
   capacity.

3.3.  Increased Uplink Bandwidth Usage

   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.
   (e.g., DSL or DOCSIS). Data Over cable Service Interface Specification
   (DOCSIS)).

3.3.1.  Facts

   1.  Data observed in Comcast's P4P trial [RFC5632] show no increase
       in the uplink traffic.

3.3.2.  Discussion

   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
   low-bandwidth 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 prime-time TV shows distributed on BitTorrent networks minutes
   after getting aired in North America).

3.3.3.  Conclusions

   Unlikely.

3.4.  Impacts on Peering Agreements

   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 that would otherwise obtain the
   most gain).  P2P traffic localization techniques aim at reducing
   cross-domain traffic and thus might also impact peering agreements.

3.4.1.  Facts

   No significant publications, simulations simulations, or trials have tried to
   understand how traffic localization techniques can influence factors
   that rule how peering agreements are established and maintained.

3.4.2.  Discussion

   This is a key topic for network operators and ISPs, and it certainly
   deserves to be analyzed more accurately.  Some random thoughts
   follow.

   It seems reasonable to expect different effects depending on the
   kinds of agreements.  For example:

   o  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
      renegotiate the contract ruling the peering agreement;

   o  ISPs with similar customer bases:

      *  ISPs with different access technologies: customers of the ISP
         which
         that 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;

      *  ISPs with similar access technologies: both ISPs would achieve
         roughly the same reduction in cross-domain traffic and thus traffic; thus, the
         conditions under which the peering agreement had been
         established would not change much.

   As a consequence of the reasoning above, it seems reasonable sensible 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.

   It's worth noting that traffic manipulation techniques have been
   reportedly used by ISPs to obtain peering agreements [Norton] with
   larger ISPs.  One of the most used technique techniques involves injecting
   forged traffic into the target ISP's network, in order to increase
   its transit costs.  Such a technique 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. bidirectional.

3.4.3.  Conclusions

   Likely.

3.5.  Impacts on Transit

   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 ISPs that are also transit providers to artificially
   increase the amount of data exchanged with networks to which they
   provide transit to (i.e. (i.e., pushing the peers run by their customers to
   establish connections with peers in the networks that pay them for
   transit).

3.5.1.  Facts

   No significant publications, simulations or trials have tried to
   study effects of traffic localization techniques on the dynamics of
   transit provision economics.

3.5.2.  Discussion

   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.

   Probably, the only lesson contentions concerning transit and peering agreement have teached taught
   us so far [CogentVsAOL] [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.

3.5.3.  Conclusions

   Likely.

3.6.  Swarm Weakening

   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.

3.6.1.  Facts

   1.  Experiments with real BitTorrent clients run by researchers at
       INRIA [LeBlond] have shown that, in BitTorrent, even when peer
       selection is heavily based on locality, swarms do not get
       damaged.

   2.  Simulations by Bell Labs [Seetharaman] indicate that the user
       experience can suffer in certain locality-aware swarms based on
       the actual implementation of locality.

3.6.2.  Discussion

   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 [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.

3.6.3.  Conclusions

   Plausible, in some circumstances.

3.7.  Improved P2P Caching

   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 [I-D.weaver-alto-edge-caches]. [EDGE-CACHES].

3.7.1.  Facts

   1.  A traffic analysis performed in a major Israeli ISP [Leibowitz]
       has shown that P2P traffic has a theoretical caching potential of
       67% byte-hit-rate.

3.7.2.  Discussion

   P2P Caching 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  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.

3.7.3.  Conclusions

   Plausible, if cost-effective for the ISP.

4.  Security Considerations

   This document is a compendium of observed issues in peer-to-peer
   networks with an informed look at whether the issue is known to
   actually exist in the network or whether the issue is, well, a non-
   issue.  As such, this document does not introduce any new security
   considerations in peer-to-peer networks.

5.  Acknowledgments

   This documents tries to summarize discussions that 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.

6.  Informative References

   [ALTO]            "Application-Layer Traffic Optimization (ALTO)
                     Working Group",
                     <http://ietf.org/html.charters/alto-charter.html>.

   [Aggarwal]        Aggarwal, V., Feldmann, A., and C. Scheidler, "Can
                     ISPs and P2P systems co-operate for improved
                     performance?", in ACM SIGCOMM Computer
                     Communications Review, vol. 37, no. 3.

   [Choffnes]        Choffnes, D. and F. Bustamante, "Taming the
                     Torrent: A practical approach to reducing cross-ISP
                     traffic in P2P systems", in ACM SIGCOMM Computer
                     Communication Review, vol. 38, no. 4.

   [CogentVsAOL]     Noguchi, Y., "Peering Dispute With AOL Slows Cogent
                     Customer Access", appeared on in the Washington Post,
                     December 17, 2002.

   [I-D.weaver-alto-edge-caches]

   [EDGE-CACHES]     Weaver, N., "Peer to Peer Localization Services and
                     Edge Caches", draft-weaver-alto-edge-caches-00 (work Work in
              progress), Progress, March 2009.

   [LeBlond]         Le Blond, S., Legout, A., and W. Dabbous, "Pushing
                     BitTorrent Locality to the Limit", available
              at http://hal.inria.fr/.
                     <http://hal.inria.fr/>.

   [Leibowitz]       Leibowitz, N., Bergman, A., Ben-Shaul, R., and A.
                     Shavit, "Are file swapping networks cacheable?
                     Characterizing p2p traffic", in proceedings of the
                     7th Int. WWW Caching Workshop.

   [Norton]          Norton, W., "The art of Peering: The peering
                     playbook",
              available from http://d.drpeering.net/. <http://d.drpeering.net/>.

   [RFC5632]         Griffiths, C., Livingood, J., Popkin, L., Woundy,
                     R., and Y. Yang, "Comcast's ISP Experiences in a
                     Proactive Network Provider Participation for P2P
                     (P4P) Technical Trial", RFC 5632, September 2009.

   [RFC5693]         Seedorf, J. and E. Burger, "Application-Layer
                     Traffic Optimization (ALTO) Problem Statement",
                     RFC 5693, October 2009.

   [Seetharaman]     Seetharaman, S., Hilt, V., Rimac, I., and M. Ammar,
                     "Applicability and Limitations of Locality-Awareness Locality-
                     Awareness in BitTorrent File-Sharing".

   [SprintVsCogent]  Ricknas, M., "Sprint-Cogent Dispute Puts Small Rip
                     in Fabric of Internet", appeared on PCWorld, PCWorld Article,
                     October 31, 2008, <http://www.pcworld.com/businesscenter/article/
              153123/
              sprintcogent_dispute_puts_small_rip_in_fabric_of_internet.
              html>.
                     <http://www.pcworld.com/businesscenter/article
                     /153123/sprintcogent_dispute_puts_small_rip_in_
                     fabric_of_internet.html>.

   [Xie]             Xie, H., Yang, Y., Krishnamurthy, A., Liu, Y., and
                     A. Silberschatz, "P4P: Explicit Communications for
                     Cooperative Control Between P2P and Network
                     Providers", in ACM SIGCOMM Computer Communication
                     Review, vol. 38, no. 4.

Appendix A.  Myths/References/Facts Matrix

   +----------------------+-------+-----------+------------+-----------+
   |                      | [Xie] | [RFC5632] | [Aggarwal] | [LeBlond] |
   +----------------------+-------+-----------+------------+-----------+
   | Cross-domain Cross-Domain Traffic | X     | X         | X          | X         |
   | (Section 3.1)        |       |           |            |           |
   | Application          | X     | X         | X          | X         |
   | Performance          |       |           |            |           |
   | (Section 3.2)        |       |           |            |           |
   | Uplink Bandwidth     |       | X         |            |           |
   | (Section 3.3)        |       |           |            |           |
   | Impacts on Peering   |       |           |            |           |
   | (Section 3.4)        |       |           |            |           |
   | Impacts on Transit   |       |           |            |           |
   | (Section 3.5)        |       |           |            |           |
   | Swarm Weakening      |       |           |            | X         |
   | (Section 3.6)        |       |           |            |           |
   | Improved P2P Caching |       |           |            |           |
   | (Section 3.7)        |       |           |            |           |
   +----------------------+-------+-----------+------------+-----------+

   +------------------------+------------+---------------+-------------+
   |                        | [Choffnes] | [Seetharaman] | [Leibowitz] |
   +------------------------+------------+---------------+-------------+
   | Cross-domain Cross-Domain Traffic   |            |               |             |
   | (Section 3.1)          |            |               |             |
   | Application            | X          | X             | X           |
   | Performance            |            |               |             |
   | (Section 3.2)          |            |               |             |
   | Uplink Bandwidth       |            |               |             |
   | (Section 3.3)          |            |               |             |
   | Impacts on Peering     |            |               |             |
   | (Section 3.4)          |            |               |             |
   | Impacts on Transit     |            |               |             |
   | (Section 3.5)          |            |               |             |
   | Swarm Weakening        |            | X             |             |
   | (Section 3.6)          |            |               |             |
   | Improved P2P Caching   |            |               | X           |
   | (Section 3.7)          |            |               |             |
   +------------------------+------------+---------------+-------------+

Authors' Addresses

   Enrico Marocco
   Telecom Italia

   Email:

   EMail: enrico.marocco@telecomitalia.it

   Antonio Fusco
   Telecom Italia

   Email:

   EMail: antonio2.fusco@telecomitalia.it

   Ivica Rimac
   Bell Labs, Alcatel-Lucent

   Email:

   EMail: rimac@bell-labs.com

   Vijay K. Gurbani
   Bell Labs, Alcatel-Lucent

   Email:

   EMail: vkg@bell-labs.com