Peer-to-peerInternet ResearchGroupTask Force (IRTF) E. MaroccoInternet-DraftRequest for Comments: 6821 A. FuscoIntended status:Category: Informational Telecom ItaliaExpires: March 24, 2013ISSN: 2070-1721 I. Rimac V. Gurbani Bell Labs, Alcatel-LucentSeptember 20,December 2012 Improving Peer Selection inPeer-to-peerPeer-to-Peer Applications: Myths vs. Realitydraft-irtf-p2prg-mythbustering-03Abstract 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,wethe 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 ofthisThis Memo ThisInternet-Draftdocument issubmitted in full conformance withnot an Internet Standards Track specification; it is published for informational purposes. This document is a product of theprovisionsInternet Research Task Force (IRTF). The IRTF publishes the results ofBCP 78Internet-related research andBCP 79. Internet-Drafts are working documentsdevelopment 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 InternetEngineeringResearch 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 amaximumcandidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status ofsix monthsthis document, any errata, and how to provide feedback on it may beupdated, replaced, or obsoleted by other documentsobtained atany 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,FactsFacts, and Discussion. . . . . . . . . . . . . . . . . 6....................................6 3.1. ReducedCross-domainCross-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,streamingstreaming, andrealtimereal-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 ininter- domaininter-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 arelooking 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 andside-effectsside 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 studieswhichthat have addressed them and trying to determine whether and in what measure they are likely to happen. Each possible effect -- orMythmyth -- 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 reasonsforsupporting andagainstopposing the myth are discussed based on the facts previously listed; o Conclusions: in which the authors try toepressexpress 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 thisdraftdocument appeared in February20092009, and there was a sizeable discussion on the contents of the document thereafter. Thedraftdocument has been improved by incorporating comments from experts in the area of peer-to-peer networks as well as casual, butinformedinformed, users of such networks. The IRTF community has helped improve the number offacts,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: frozensnapshotin 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 withit. 2.1. Seederthe 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. LeecherLeecher: 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 anddownloading, alsodownloading and are used in other kinds of P2P applications.2.3. SwarmSwarm: 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 exchangingchunckschunks of a particular file; however, in thisdocumentdocument, it is used moregenerally, for example,generally (e.g., in the case of P2P streamingapplications,applications) to refer to all peers receiving and/or transmitting the same media stream.2.4. Tit-for-tatTit-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.SurplusModeMode: 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. TransitTransit: The service through which a network can exchange IP packets with all other networks to which it is not directlyconnected to.connected. The transit service is always regulated by a contract, according to which thecustumer (i.e.customer (i.e., a network operator or an ISP) pays the transit provider per amount of data exchanged.2.7. PeeringPeering: The direct interconnection between two separate networks for the purpose of exchanging traffic withoutrecurring torequiring 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,FactsFacts, and Discussion 3.1. ReducedCross-domainCross-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 reasonwaywhy 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 atTUTechnischen 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 perASAutonomous 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 thataton 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-AStraffic ,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 sharingfile-sharing applications witness an increase in the download rate,realtimereal-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] showandan 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 ofRDSNET,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 thetraffic 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, forexampleexample, 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 peersareis 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 orDOCSIS).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 locallow-bandwiwthlow-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 ofprime timeprime-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 partywhichthat 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,simulationssimulations, 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 tore-negotiaterenegotiate the contract ruling the peering agreement; o ISPs with similar customer bases: * ISPs with different access technologies: customers of the ISPwhichthat 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-domaintraffic and thustraffic; thus, the conditions under which the peering agreement had been established would not change much. As a consequence of the reasoning above, it seemsreasonablesensible 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 usedtechniquetechniques 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 alsobi-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 thoseISPISPs that are also transit providers to artificially increase the amount of data exchanged with networks to which they provide transitto (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 lessoncontentions concerningtransit and peering agreement haveteachedtaught us so far [CogentVsAOL] [SprintVsCogent] is that, at the end of the day, no economic factor, no matter howmuchrelevant 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 P2PCachingcaching may be beneficial for both ISPs and network users, and locality-based optimizations may help the ISP to direct the peers towards caches.AnywayAnyway, 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", appearedonin 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 (workWork inprogress),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 ofLocality-AwarenessLocality- Awareness in BitTorrent File-Sharing". [SprintVsCogent] Ricknas, M., "Sprint-Cogent Dispute Puts Small Rip in Fabric of Internet",appeared on PCWorld,PCWorld Article, October31,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-domainCross-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-domainCross-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 ItaliaEmail:EMail: enrico.marocco@telecomitalia.it Antonio Fusco Telecom ItaliaEmail:EMail: antonio2.fusco@telecomitalia.it Ivica Rimac Bell Labs, Alcatel-LucentEmail:EMail: rimac@bell-labs.com Vijay K. Gurbani Bell Labs, Alcatel-LucentEmail:EMail: vkg@bell-labs.com