idnits 2.17.1 draft-irtf-p2prg-mythbustering-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 20, 2012) is 4229 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Peer-to-peer Research Group E. Marocco 3 Internet-Draft A. Fusco 4 Intended status: Informational Telecom Italia 5 Expires: March 24, 2013 I. Rimac 6 V. Gurbani 7 Bell Labs, Alcatel-Lucent 8 September 20, 2012 10 Improving Peer Selection in Peer-to-peer Applications: Myths vs. Reality 11 draft-irtf-p2prg-mythbustering-03 13 Abstract 15 Peer-to-peer traffic optimization techniques that aim at improving 16 locality in the peer selection process have attracted great interest 17 in the research community and have been subject of much discussion. 18 Some of this discussion has produced controversial myths, some rooted 19 in reality while others remain unfounded. This document evaluates 20 the most prominent myths attributed to P2P optimization techniques by 21 referencing the most relevant study (or studies) that have addressed 22 facts pertaining to the myth. Using these studies, we hope to either 23 confirm or refute each specific myth. 25 This document is a product of the IRTF P2PRG (peer-to-peer research 26 group). 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on March 24, 2013. 45 Copyright Notice 47 Copyright (c) 2012 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 2.1. Seeder . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 2.2. Leecher . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 2.3. Swarm . . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 2.4. Tit-for-tat . . . . . . . . . . . . . . . . . . . . . . . 5 68 2.5. Surplus Mode . . . . . . . . . . . . . . . . . . . . . . . 6 69 2.6. Transit . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 2.7. Peering . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 3. Myths, Facts and Discussion . . . . . . . . . . . . . . . . . 6 72 3.1. Reduced Cross-domain Traffic . . . . . . . . . . . . . . . 6 73 3.1.1. Facts . . . . . . . . . . . . . . . . . . . . . . . . 6 74 3.1.2. Discussion . . . . . . . . . . . . . . . . . . . . . . 7 75 3.1.3. Conclusions . . . . . . . . . . . . . . . . . . . . . 7 76 3.2. Increased Application Performance . . . . . . . . . . . . 7 77 3.2.1. Facts . . . . . . . . . . . . . . . . . . . . . . . . 7 78 3.2.2. Discussion . . . . . . . . . . . . . . . . . . . . . . 8 79 3.2.3. Conclusions . . . . . . . . . . . . . . . . . . . . . 8 80 3.3. Increased Uplink Bandwidth Usage . . . . . . . . . . . . . 8 81 3.3.1. Facts . . . . . . . . . . . . . . . . . . . . . . . . 8 82 3.3.2. Discussion . . . . . . . . . . . . . . . . . . . . . . 8 83 3.3.3. Conclusions . . . . . . . . . . . . . . . . . . . . . 9 84 3.4. Impacts on Peering Agreements . . . . . . . . . . . . . . 9 85 3.4.1. Facts . . . . . . . . . . . . . . . . . . . . . . . . 9 86 3.4.2. Discussion . . . . . . . . . . . . . . . . . . . . . . 9 87 3.4.3. Conclusions . . . . . . . . . . . . . . . . . . . . . 10 88 3.5. Impacts on Transit . . . . . . . . . . . . . . . . . . . . 10 89 3.5.1. Facts . . . . . . . . . . . . . . . . . . . . . . . . 10 90 3.5.2. Discussion . . . . . . . . . . . . . . . . . . . . . . 10 91 3.5.3. Conclusions . . . . . . . . . . . . . . . . . . . . . 11 92 3.6. Swarm Weakening . . . . . . . . . . . . . . . . . . . . . 11 93 3.6.1. Facts . . . . . . . . . . . . . . . . . . . . . . . . 11 94 3.6.2. Discussion . . . . . . . . . . . . . . . . . . . . . . 11 95 3.6.3. Conclusions . . . . . . . . . . . . . . . . . . . . . 11 96 3.7. Improved P2P Caching . . . . . . . . . . . . . . . . . . . 11 97 3.7.1. Facts . . . . . . . . . . . . . . . . . . . . . . . . 12 98 3.7.2. Discussion . . . . . . . . . . . . . . . . . . . . . . 12 99 3.7.3. Conclusions . . . . . . . . . . . . . . . . . . . . . 12 100 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 101 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 102 6. Informative References . . . . . . . . . . . . . . . . . . . . 12 103 Appendix A. Myths/References/Facts Matrix . . . . . . . . . . . . 14 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 106 1. Introduction 108 Peer-to-peer (P2P) applications used for file-sharing, streaming and 109 realtime communications exchange large amounts of data in connections 110 established among the peers themselves and are responsible for an 111 important part of the Internet traffic. Since applications have 112 generally no knowledge of the underlying network topology, the 113 traffic they generate is frequent cause of congestions in inter- 114 domain links and significantly contributes to the raising of transit 115 costs paid by network operators and Internet Service Providers (ISP). 117 One approach to reduce congestions and transit costs caused by P2P 118 applications consists of enhancing the peer selection process with 119 the introduction of proximity information. This allows the peers to 120 identify the topologically closer resource among all the instances of 121 the resources they are looking for. Several solutions following such 122 an approach have recently been proposed [Choffnes] [Aggarwal] [Xie], 123 some of which are now being considered for standardization in the 124 IETF [ALTO]. While this document serves to inform the protocol work 125 going on in the IETF ALTO working group, this document does not 126 specify a protocol of any kind, nor is this document a product of the 127 IETF. 129 Despite extensive research based on simulations and field trials, it 130 is hard to predict how proposed solutions would perform in a real- 131 world systems made of millions of peers. For this reason, possible 132 effects and side-effects of optimization techniques based on P2P 133 traffic localization have been a matter of frequent debate. This 134 document describes some of the most interesting effects, referencing 135 relevant studies which have addressed them and trying to determine 136 whether and in what measure they are likely to happen. 138 Each possible effect -- or Myth -- is examined in three phases: 139 o Facts: in which a list of relevant data is presented, usually 140 collected from simulations or field trials; 141 o Discussion: in which the reasons for and against the myth are 142 discussed based on the facts previously listed; 143 o Conclusions: in which the authors try to epress a reasonable 144 measure of the plausibility of the myth. 146 This document represents the consensus of the P2PRG. The first 147 version of this draft appeared in February 2009 and there was a 148 sizeable discussion on the contents of the document thereafter. The 149 draft has been improved by incorporating comments from experts in the 150 area of peer-to-peer networks as well as casual, but informed users 151 of such networks. The IRTF community has helped improve the number 152 of facts, quality of discussion and enhanced the trustworthiness of 153 the conclusions documented. 155 This document essentially represents the view of the participating 156 P2PRG IRTF community between 2009 and the latter part of 2010; as 157 such, it is a frozen snapshot in time. While some aspects are 158 confirmed with references to pertinent literature, other aspects 159 reflect the state of discussions in the RG at the time of writing and 160 may require further investigation beyond the publication date of this 161 document. 163 2. Definitions 165 Terminology defined in [RFC5693] is reused here; other definitions 166 should be consistent with it. 168 2.1. Seeder 170 A peer that has a complete copy of the content it is sharing, and 171 still offers it for upload. The term "seeder" is adopted from 172 BitTorrent terminology and is used in this document to indicate 173 upload-only peers also in other kinds of P2P applications. 175 2.2. Leecher 177 A peer that has not yet completed the download of a specific content 178 (but usually has already started offering for upload the part it is 179 in possession of). The term "leecher" is adopted from BitTorrent 180 terminology and is used in this document to indicate peers that are 181 both uploading and downloading, also in other kinds of P2P 182 applications. 184 2.3. Swarm 186 The group of peers that are uploading and/or downloading pieces of 187 the same content. The term "swarm" is commonly used in BitTorrent, 188 to indicate all seeders and leechers exchanging chuncks of a 189 particular file; however, in this document it is used more generally, 190 for example, in the case of P2P streaming applications, to refer to 191 all peers receiving and/or transmitting the same media stream. 193 2.4. Tit-for-tat 195 A content exchange strategy where the amount of data sent by a 196 leecher to another leecher is roughly equal to the amount of data 197 received from it. P2P applications, most notably BitTorrent, adopt 198 such an approach to maximize resources shared by the users. 200 2.5. Surplus Mode 202 The status of a swarm where the upload capacity exceeds the download 203 demand. A swarm in surplus mode is often referred to as "well 204 seeded". 206 2.6. Transit 208 The service through which a network can exchange IP packets with all 209 other networks it is not directly connected to. The transit service 210 is always regulated by a contract, according to which the custumer 211 (i.e. a network operator or an ISP) pays the transit provider per 212 amount of data exchanged. 214 2.7. Peering 216 The direct interconnection between two separate networks for the 217 purpose of exchanging traffic without recurring to a transit 218 provider. Peering is usually regulated by agreements taking in 219 account the amount of traffic generated by each party in each 220 direction. 222 3. Myths, Facts and Discussion 224 3.1. Reduced Cross-domain Traffic 226 The reduction in cross-domain traffic (and thus in transit costs due 227 to it) is one of the positive effects P2P traffic localization 228 techniques are expected to cause, and also the main reason way ISPs 229 look at them with interest. Simulations and field tests have shown a 230 reduction varying from 20% to 80%. 232 3.1.1. Facts 234 1. Various simulations and initial field trials of the P4P solution 235 [Xie] on average show a 70% reduction of cross-domain traffic. 236 2. Data observed in Comcast's P4P trial [RFC5632] show a 34% 237 reduction of the outgoing P2P traffic and an 80% reduction of the 238 incoming. 239 3. Simulations of the "oracle-based" approach [Aggarwal] proposed by 240 researchers at TU Berlin show an increase in local exchanges from 241 10% in the unbiased case to 60%-80% in the localized case. 242 4. Experiments with real BitTorrent clients and real distributions 243 of peers per AS run by researchers at INRIA [LeBlond] have shown 244 that ASes with 100 peers or more can save 99.5% of cross-domain 245 traffic with high values of locality. They have also shown that 246 at a global scale, i.e., 214,443 torrents, 6,1113,224 unique 247 peers, and 9,605 ASes, high locality can save 40% of global 248 inter-AS traffic , i.e., 4.56 Petabytes (PB) on 11.6 PB. This 249 result shows that locality would be beneficial at the scale of 250 the Internet. 252 3.1.2. Discussion 254 Tautologically, P2P traffic localization techniques tend to localize 255 content exchanges, and thus reduce cross-domain traffic. 257 3.1.3. Conclusions 259 Confirmed. 261 3.2. Increased Application Performance 263 Ostensibly, the increase in application performance is the main 264 reason for the consideration of P2P traffic localization techniques 265 in academia and industry. The expected increase depends on the 266 specific application: file sharing applications witness an increase 267 in the download rate, realtime communication applications observe 268 lower delay and jitter, and streaming applications can benefit by a 269 high constant bitrate. 271 3.2.1. Facts 273 1. Various simulations and initial field trials of the P4P solution 274 [Xie] show an average reduction of download completion times 275 between 10% and 23%. 276 2. Data observed in Comcast's P4P trial [RFC5632] show and increase 277 in download rates between 13% and 85%. Interestingly, the data 278 collected in the experiment also indicate that fine-grained 279 localization is less effective in improving download performance 280 compared to lower levels of localization. 281 3. Data collected in the Ono experiment [Choffnes] show a 31% 282 average download rate improvement. 283 * In networks where the ISP provides higher bandwidth for in- 284 network traffic (e.g. as in the case of RDSNET, described in 285 [Choffnes]), the increase is significantly higher. 286 * In networks with relatively low uplink bandwidth (as the case 287 of Easynet, described in [Choffnes]), traffic localization 288 slightly degrades application performance. 289 4. Simulations of the "oracle-based" approach [Aggarwal] proposed by 290 researchers at TU Berlin show a reduction in download times 291 between 16% and 34%. 292 5. Simulations by Bell Labs [Seetharaman] indicate that localization 293 is not as effective in all scenarios and that the user experience 294 can suffer in certain locality-aware swarms based on the actual 295 implementation of locality. 296 6. Experiments with real clients run by researchers at INRIA 297 [LeBlond] have shown that the measured application performance is 298 a function of the degree of congestion on links the locality 299 policy tries to reduce the traffic on. Furthermore, they have 300 also shown that, in the case of severe bottlenecks, BitTorrent 301 with locality can be more than 200% faster than regular 302 BitTorrent. 304 3.2.2. Discussion 306 It seems that traffic localization techniques often cause an 307 improvement in application performance. However, it must be noted 308 that such beneficial effects heavily depend on the network 309 infrastructures. In some cases, for example in networks with 310 relatively low uplink bandwidth, localization seems to be useless if 311 not harmful. Also, beneficial effects depend on the swarm size; 312 imposing locality when only a small set of local peers are available 313 may even decrease download performance for local peers. 315 3.2.3. Conclusions 317 Very likely, especially for large swarms and in networks with high 318 capacity. 320 3.3. Increased Uplink Bandwidth Usage 322 The increase in uplink bandwidth usage would be a negative effect, 323 especially in environments where the access network is based on 324 technologies providing asymmetric upstream/downstream bandwidth (e.g. 325 DSL or DOCSIS). 327 3.3.1. Facts 329 1. Data observed in Comcast's P4P trial [RFC5632] show no increase 330 in the uplink traffic. 332 3.3.2. Discussion 334 Mathematically, average uplink traffic remains the same as long as 335 the swarm is not in surplus mode. However, in some particular cases 336 where surplus capacity is available, localization may lead to local 337 low-bandwiwth leechers connecting to each other instead of trying the 338 external seeders. Even if such a phenomenon has not been observed in 339 simulations and field trials, it could occur to applications that use 340 localization as the only means for optimization when some content 341 becomes popular in different areas at different times (as is the case 342 of prime time TV shows distributed on BitTorrent networks minutes 343 after getting aired in North America). 345 3.3.3. Conclusions 347 Unlikely. 349 3.4. Impacts on Peering Agreements 351 Peering agreements are usually established on a reciprocity basis, 352 assuming that the amount of data sent and received by each party is 353 roughly the same (or, in case of asymmetric traffic volumes, a 354 compensation fee is paid by the party which would otherwise obtain 355 the most gain). P2P traffic localization techniques aim at reducing 356 cross-domain traffic and thus might also impact peering agreements. 358 3.4.1. Facts 360 No significant publications, simulations or trials have tried to 361 understand how traffic localization techniques can influence factors 362 that rule how peering agreements are established and maintained. 364 3.4.2. Discussion 366 This is a key topic for network operators and ISPs, and certainly 367 deserves to be analyzed more accurately. Some random thoughts 368 follow. 370 It seems reasonable to expect different effects depending on the 371 kinds of agreements. For example: 372 o ISPs with different customer bases: the ISP whose customers 373 generate more P2P traffic can achieve a greater reduction of 374 cross-domain traffic and thus could probably be in a position to 375 re-negotiate the contract ruling the peering agreement; 376 o ISPs with similar customer bases: 377 * ISPs with different access technologies: customers of the ISP 378 which provides higher bandwidth -- and, in particular, higher 379 uplink bandwidth -- will have more incentives for keeping their 380 P2P traffic local. Consequently, the ISP with a better 381 infrastructure will be able to achieve a greater reduction in 382 cross-domain traffic and will be probably in a position to re- 383 negotiate the peering agreement; 384 * ISPs with similar access technologies: both ISPs would achieve 385 roughly the same reduction in cross-domain traffic and thus the 386 conditions under which the peering agreement had been 387 established would not change much. 389 As a consequence of the reasoning above, it seems reasonable to 390 expect that the simple fact that one ISP starts localizing its P2P 391 traffic will be a strong incentive for the ISPs it peers with to do 392 that as well. 394 It's worth noting that traffic manipulation techniques have been 395 reportedly used by ISPs to obtain peering agreements [Norton] with 396 larger ISPs. One of the most used technique involves injecting 397 forged traffic into the target ISP's network, in order to increase 398 its transit costs. Such a technique aims at increasing the relevance 399 of the source ISP in the target's transit bill and thus motivate the 400 latter to sign a peering agreement. However, traffic injection is 401 exclusively unidirectional and easy to detect. On the other hand, if 402 a localization-like service were used to direct P2P requests toward 403 the target network, the resulting traffic would appear fully 404 legitimate and, since in popular applications that follow the tit- 405 for-tat approach peers tend to upload to the peers they download 406 from, in many cases also bi-directional. 408 3.4.3. Conclusions 410 Likely. 412 3.5. Impacts on Transit 414 One of the main goals of P2P traffic localization techniques is to 415 allow ISPs to keep local a part of the traffic generated by their 416 customers and thus save on transit costs. However, similar 417 techniques based on de-localization rather than localization may be 418 used by those ISP that are also transit providers to artificially 419 increase the amount of data exchanged with networks they provide 420 transit to (i.e. pushing the peers run by their customers to 421 establish connections with peers in the networks that pay them for 422 transit). 424 3.5.1. Facts 426 No significant publications, simulations or trials have tried to 427 study effects of traffic localization techniques on the dynamics of 428 transit provision economics. 430 3.5.2. Discussion 432 It is actually very hard to predict how the economics of transit 433 provision would be affected by the tricks some transit providers 434 could play on their customers making use of P2P traffic localization 435 -- or, in this particular case, de-localization -- techniques. This 436 is also a key topic for ISPs, definitely worth an accurate 437 investigation. 439 Probably, the only lesson contentions concerning transit and peering 440 agreement have teached so far [CogentVsAOL] [SprintVsCogent] is that, 441 at the end of the day, no economic factor, no matter how much 442 relevant it is, is able to isolate different networks from each 443 other. 445 3.5.3. Conclusions 447 Likely. 449 3.6. Swarm Weakening 451 Peer selection techniques based on locality information are certainly 452 beneficial in areas where the density of peers is high enough, but 453 may cause damages otherwise. Some studies have tried to understand 454 to what extent locality can be pushed without damaging peers in 455 isolated parts of the network. 457 3.6.1. Facts 459 1. Experiments with real BitTorrent clients run by researchers at 460 INRIA [LeBlond] have shown that, in BitTorrent, even when peer 461 selection is heavily based on locality, swarms do not get 462 damaged. 463 2. Simulations by Bell Labs [Seetharaman] indicate that the user 464 experience can suffer in certain locality-aware swarms based on 465 the actual implementation of locality. 467 3.6.2. Discussion 469 It seems reasonable to expect that excessive traffic localization 470 will cause some degree of deterioration in P2P swarms based on the 471 tit-for-tat approach, and the damages of such deterioration will 472 likely affect most users in networks with lower density of peers. 473 However, while [LeBlond] shows that BitTorrent is extremely robust, 474 the level of tolerance to locality for different P2P algorithms 475 should be evaluated on a case-by-case basis. 477 3.6.3. Conclusions 479 Plausible, in some circumstances. 481 3.7. Improved P2P Caching 483 P2P caching has been proposed as a possible solution to reduce cross- 484 domain as well as uplink P2P traffic. Since the cache servers 485 ultimately act as seeders, a cache-aware localization service would 486 allow a seamless integration of a caching infrastructure with P2P 487 applications [I-D.weaver-alto-edge-caches]. 489 3.7.1. Facts 491 1. A traffic analysis performed in a major Israeli ISP [Leibowitz] 492 has shown that P2P traffic has a theoretical caching potential of 493 67% byte-hit-rate. 495 3.7.2. Discussion 497 P2P Caching may be beneficial for both ISPs and network users, and 498 locality-based optimizations may help the ISP to direct the peers 499 towards caches. Anyway it is hard to figure at this point in time if 500 the positive effects of localization will make caching superfluous or 501 not economically justifiable for the ISP. 503 3.7.3. Conclusions 505 Plausible, if cost-effective for the ISP. 507 4. Security Considerations 509 This document is a compendium of observed issues in peer-to-peer 510 networks with an informed look at whether the issue is known to 511 actually exist in the network or whether the issue is, well, a non- 512 issue. As such, this document does not introduce any new security 513 considerations in peer-to-peer networks. 515 5. Acknowledgments 517 This documents tries to summarize discussions happened in live 518 meetings and on several mailing lists: all those who are reading this 519 have probably contributed more ideas and more material than the 520 authors themselves. 522 6. Informative References 524 [ALTO] "Application-Layer Traffic Optimization (ALTO) Working 525 Group", . 527 [Aggarwal] 528 Aggarwal, V., Feldmann, A., and C. Scheidler, "Can ISPs 529 and P2P systems co-operate for improved performance?", 530 in ACM SIGCOMM Computer Communications Review, vol. 37, 531 no. 3. 533 [Choffnes] 534 Choffnes, D. and F. Bustamante, "Taming the Torrent: A 535 practical approach to reducing cross-ISP traffic in P2P 536 systems", in ACM SIGCOMM Computer Communication Review, 537 vol. 38, no. 4. 539 [CogentVsAOL] 540 Noguchi, Y., "Peering Dispute With AOL Slows Cogent 541 Customer Access", appeared on Washington Post, December 542 17, 2002. 544 [I-D.weaver-alto-edge-caches] 545 Weaver, N., "Peer to Peer Localization Services and Edge 546 Caches", draft-weaver-alto-edge-caches-00 (work in 547 progress), March 2009. 549 [LeBlond] Le Blond, S., Legout, A., and W. Dabbous, "Pushing 550 BitTorrent Locality to the Limit", available 551 at http://hal.inria.fr/. 553 [Leibowitz] 554 Leibowitz, N., Bergman, A., Ben-Shaul, R., and A. Shavit, 555 "Are file swapping networks cacheable? Characterizing p2p 556 traffic", in proceedings of the 7th Int. WWW Caching 557 Workshop. 559 [Norton] Norton, W., "The art of Peering: The peering playbook", 560 available from http://d.drpeering.net/. 562 [RFC5632] Griffiths, C., Livingood, J., Popkin, L., Woundy, R., and 563 Y. Yang, "Comcast's ISP Experiences in a Proactive Network 564 Provider Participation for P2P (P4P) Technical Trial", 565 RFC 5632, September 2009. 567 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 568 Optimization (ALTO) Problem Statement", RFC 5693, 569 October 2009. 571 [Seetharaman] 572 Seetharaman, S., Hilt, V., Rimac, I., and M. Ammar, 573 "Applicability and Limitations of Locality-Awareness in 574 BitTorrent File-Sharing". 576 [SprintVsCogent] 577 Ricknas, M., "Sprint-Cogent Dispute Puts Small Rip in 578 Fabric of Internet", appeared on PCWorld, October 31, 579 2008, . 584 [Xie] Xie, H., Yang, Y., Krishnamurthy, A., Liu, Y., and A. 585 Silberschatz, "P4P: Explicit Communications for 586 Cooperative Control Between P2P and Network Providers", 587 in ACM SIGCOMM Computer Communication Review, vol. 38, no. 588 4. 590 Appendix A. Myths/References/Facts Matrix 592 +----------------------+-------+-----------+------------+-----------+ 593 | | [Xie] | [RFC5632] | [Aggarwal] | [LeBlond] | 594 +----------------------+-------+-----------+------------+-----------+ 595 | Cross-domain Traffic | X | X | X | X | 596 | (Section 3.1) | | | | | 597 | Application | X | X | X | X | 598 | Performance | | | | | 599 | (Section 3.2) | | | | | 600 | Uplink Bandwidth | | X | | | 601 | (Section 3.3) | | | | | 602 | Impacts on Peering | | | | | 603 | (Section 3.4) | | | | | 604 | Impacts on Transit | | | | | 605 | (Section 3.5) | | | | | 606 | Swarm Weakening | | | | X | 607 | (Section 3.6) | | | | | 608 | Improved P2P Caching | | | | | 609 | (Section 3.7) | | | | | 610 +----------------------+-------+-----------+------------+-----------+ 612 +------------------------+------------+---------------+-------------+ 613 | | [Choffnes] | [Seetharaman] | [Leibowitz] | 614 +------------------------+------------+---------------+-------------+ 615 | Cross-domain Traffic | | | | 616 | (Section 3.1) | | | | 617 | Application | X | X | X | 618 | Performance | | | | 619 | (Section 3.2) | | | | 620 | Uplink Bandwidth | | | | 621 | (Section 3.3) | | | | 622 | Impacts on Peering | | | | 623 | (Section 3.4) | | | | 624 | Impacts on Transit | | | | 625 | (Section 3.5) | | | | 626 | Swarm Weakening | | X | | 627 | (Section 3.6) | | | | 628 | Improved P2P Caching | | | X | 629 | (Section 3.7) | | | | 630 +------------------------+------------+---------------+-------------+ 632 Authors' Addresses 634 Enrico Marocco 635 Telecom Italia 637 Email: enrico.marocco@telecomitalia.it 639 Antonio Fusco 640 Telecom Italia 642 Email: antonio2.fusco@telecomitalia.it 644 Ivica Rimac 645 Bell Labs, Alcatel-Lucent 647 Email: rimac@bell-labs.com 649 Vijay K. Gurbani 650 Bell Labs, Alcatel-Lucent 652 Email: vkg@bell-labs.com