<?xml version='1.0' encoding='US-ASCII'?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<!DOCTYPE rfc SYSTEM 'rfcXXXX.dtd'>

<rfc submissionType="IRTF" category='info' consensus="yes" ipr='trust200902' number='6821'>

<?rfc toc='yes' ?>
<?rfc symrefs='yes' ?>
<?rfc sortrefs='yes'?>
<?rfc iprnotified='no' ?>
<?rfc strict='no' ?>
<?rfc compact='yes' ?>
<?rfc subcompact='no' ?>
<?rfc rfcedstyle='yes'?>

<front>

  <title abbrev='Peer Selection in P2P Applications'>
    Improving&nbsp;Peer&nbsp;Selection&nbsp;in&nbsp;Peer-to-Peer&nbsp;Applications: Myths&nbsp;vs.&nbsp;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@bell-labs.com</email>
    </address>
  </author>

  <date month="December" year="2012"/>

  <workgroup>Peer-to-peer Research Group</workgroup>


  <abstract>
    <t>
      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 that have addressed facts
      pertaining to the myth. Using these studies, the authors hope to either
      confirm or refute each specific myth.</t>
      <t></t>
      <t>This document is a product of the IRTF P2PRG (Peer-to-Peer Research
      Group).</t>
  </abstract>

</front>

<middle>
  <section title='Introduction'>
    <t>
      Peer-to-peer (P2P) applications used for file-sharing, streaming,
      and 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 links and significantly contributes
      to the raising of transit costs paid by network operators and
      Internet Service Providers (ISPs).
    </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 searching through.


      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'/>.  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.  
    </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 that 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 supporting and opposing the myth are
      discussed based on the facts previously listed;
        </t>
        <t>
          Conclusions: in which the authors try to express a reasonable
          measure of the plausibility of the myth.
          <vspace blankLines="1"/>
          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.
        </t>
      </list>
    </t>
    <t>
      This document represents the consensus of the P2PRG.  The first
      version of this document appeared in February 2009, and there was a
      sizeable discussion on the contents of the document thereafter.
      The document has been improved by incorporating comments from experts
      in the area of peer-to-peer networks as well as casual, but informed,
      users of such networks.  The IRTF community has helped improve the
      number of facts and quality of discussion and enhanced the trustworthiness
      of the conclusions documented.

    </t>
    <t>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 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.</t>
  </section>

  <section title='Definitions'>
    <t>
      Terminology defined in <xref target='RFC5693'/> is reused here;
      other definitions should be consistent with the terminology in that document.
    </t>

<list style="hanging" hangIndent="3">
    <t hangText='Seeder:'><vspace blankLines="1" />
        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.
      </t>
   
    <t hangText='Leecher:'> <vspace blankLines="1"/>
        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 and are used in other kinds of P2P applications.
      </t>

    <t hangText='Swarm:'><vspace blankLines="1"/>
        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
        chunks of a particular file; however, in this document, it is
        used more generally  (e.g., in the case of P2P streaming
        applications) to refer to all peers receiving and/or
        transmitting the same media stream.
      </t>
    <t hangText='Tit-for-Tat:'> <vspace blankLines="1" />
        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>
    <t hangText='Surplus Mode:'><vspace blankLines="1" />
        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>
   
    <t hangText='Transit:'><vspace blankLines="1" />
      
        The service through which a network can exchange IP packets
        with all other networks to which it is not directly connected. The
        transit service is always regulated by a contract, according
        to which the customer (i.e., a network operator or an ISP) pays
        the transit provider per amount of data exchanged.
      </t>
    
    <t hangText='Peering:'><vspace blankLines="1" />
        The direct interconnection between two separate networks for the
  purpose of exchanging traffic without requiring a transit provider. Peering is usually regulated by agreements
        taking in account the amount of traffic generated by each
        party in each direction.
      </t>
 </list>

  </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 why 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 Technischen Universitat Berlin (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 Autonomous System (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
              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, 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, real-time
        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 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.
            </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
                  a Romanian ISP (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 on which the locality policy tries
              to reduce the 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.
            </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 is 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 Data Over cable Service Interface Specification (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-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 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 that
        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 it
          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 renegotiate 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 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;
                </t>
                <t>
                  ISPs with similar access technologies: both ISPs
                  would achieve roughly the same reduction in
                  cross-domain traffic; 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 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.
        </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 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 bidirectional.
        </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 ISPs that are also transit
        providers to artificially increase the amount of data
        exchanged with networks to which they provide transit (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 transit and
          peering agreement have taught us so far <xref
          target='CogentVsAOL'/> <xref target='SprintVsCogent'/> is
          that, at the end of the day, no economic factor, no matter
          how 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='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>
      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.
    </t>
  </section>

  <section title='Acknowledgments'>
    <t>
      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.
    </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' />
<abstract>
<t>This document describes the experiences of Comcast, a large cable broadband Internet Service Provider (ISP) in the U.S., in a Proactive Network Provider Participation for P2P (P4P) technical trial in July 2008.  This trial used P4P iTracker technology, which is being considered by the IETF as part of the Application Layer Transport Optimization (ALTO) working group.  This memo provides information for the Internet community.</t></abstract></front>

<seriesInfo name='RFC' value='5632' />
<format type='TXT' octets='27920' target='http://www.rfc-editor.org/rfc/rfc5632.txt' />
</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' />
<abstract>
<t>Distributed applications -- such as file sharing, real-time communication, and live and on-demand media streaming -- prevalent on the Internet use a significant amount of network resources. Such applications often transfer large amounts of data through connections established between nodes distributed across the Internet with little knowledge of the underlying network topology. Some applications are so designed that they choose a random subset of peers from a larger set with which to exchange data. Absent any topology information guiding such choices, or acting on suboptimal or local information obtained from measurements and statistics, these applications often make less than desirable choices.&lt;/t>&lt;t> This document discusses issues related to an information-sharing service that enables applications to perform better-than-random peer selection. This memo provides information for the Internet community.</t></abstract></front>

<seriesInfo name='RFC' value='5693' />
<format type='TXT' octets='34234' target='http://www.rfc-editor.org/rfc/rfc5693.txt' />
</reference>



    <reference anchor='LeBlond' target="http://hal.inria.fr/">
      <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>
      <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' target="http://d.drpeering.net/">
      <front>
        <title>
          The art of Peering: The peering playbook
        </title>
          <author initials='W' surname='Norton'>
            <organization/>
          </author>
      </front>
 
    </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>

<!-- I-D.weaver-alto-edge-caches; Expired -->

    <reference anchor='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='Work in'
                  value='Progress' />
      </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=''>
         
        </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 in the" 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>
        <date month='October' day='31' year='2008' />
      </front>
      <seriesInfo name="PCWorld" value="Article"/>
    </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>
