idnits 2.17.1 draft-saumitra-alto-multi-ps-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 608. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 619. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 626. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 632. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 23, 2008) is 5663 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Das 3 Internet-Draft V. Narayanan 4 Intended status: Standards Track L. Dondeti 5 Expires: April 26, 2009 Qualcomm, Inc. 6 October 23, 2008 8 ALTO: A Multi Dimensional Peer Selection Problem 9 draft-saumitra-alto-multi-ps-00 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 26, 2009. 36 Abstract 38 Bulk data applications are posing serious challenges to the Internet 39 infrastructure and more mass adoption of such applications would only 40 increase that challenge. P2P bulk data applications and other large 41 volume HTTP traffic such as video currently dominate the Internet 42 traffic. These applications do not generally benefit from the 43 traffic engineering techniques developed for the Internet. In the 44 HTTP traffic case, the traffic optimization issues are often 45 addressed using the CDN infrastructure. For P2P bulk data 46 applications, the problem is about picking the right peers to 47 communicate with and the criteria for doing this vary greatly based 48 on the application. Hence, intelligent peer selection is the 49 fundamental problem to address for these applications. This document 50 explains the multiple dimensions of the peer selection problem with 51 respect to obtaining information from the network as well from other 52 peers and argues for an integrated, common framework to share such 53 information. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 60 3.1. Network-assisted ALTO . . . . . . . . . . . . . . . . . . 6 61 3.2. Peer-assisted ALTO . . . . . . . . . . . . . . . . . . . . 6 62 3.3. The need for multiple criterion . . . . . . . . . . . . . 6 63 3.3.1. Peer-assisted ALTO alone . . . . . . . . . . . . . . . 7 64 3.3.2. Network-assisted ALTO alone . . . . . . . . . . . . . 7 65 3.4. Applicability and Discussion . . . . . . . . . . . . . . . 8 66 4. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 69 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 71 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 72 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 74 Intellectual Property and Copyright Statements . . . . . . . . . . 14 76 1. Introduction 78 A large portion of the Internet traffic today is from P2P (peer-to- 79 peer) applications. Such an architecture for data transfer is 80 attractive because it reduces the bandwidth costs of the content 81 provider since they simply need to seed the content to a few nodes in 82 the network which would then contribute upload bandwidth to assist 83 the content provider's servers in the data transfer. Thus, the 84 single point bottleneck at the content provider is eliminated and 85 both users and content providers benefit. 87 However such an approach is detrimental to another important entity 88 in the system: the ISPs. While p2p has led to increased popularity 89 of broadband connections and arguably increased subscribers for ISPs; 90 it has also increased traffic costs for the ISPs. This is because 91 P2P applications' peer selection does not consider underlying network 92 topology and link costs in that topology. Most p2p applications 93 typically are only interested in improving their data transfer 94 performance which is satisfied if the download link of the user is 95 saturated. As shown in [2], traffic generated by popular P2P 96 applications often cross network boundaries multiple times, 97 overloading links which are frequently subject to congestion [3]. 98 This happens because most p2p applications simply use random peer 99 selection followed by monitoring and reevaluation. Even if p2p 100 applications perform some network measurements, these typically tend 101 to be round trip time estimation which may or may not lead to peer 102 selection conducive to ISP interests. 104 This led to ISPs efforts at shaping or blocking P2P traffic on 105 specific ports. In response, p2p applictions started using dynamic 106 ports to transfer data following whcih ISPs had to use deep packet 107 protocol specific information to shape p2p flows. In response, p2p 108 applications have started encrypting their connections. The use of 109 TCP RST messages to deter costly p2p application data transfer has 110 led to some conflicts as well. It is in the ISP's interests to avoid 111 the cat-and-mouse games of protocol-specific detection and mitigation 112 while still not having to increase costs significantly to accomodate 113 p2p traffic. 115 One way to reduce the impact on ISPs would be the deployment of 116 caching entities in the networks to reduce cross-ISP traffic and 117 network distance of data transfer. However such an approach has 118 several issues: 120 o It is not clear who would deploy these high-bandwidth large- 121 storage capable caches since it can be argued that caching pushes 122 the costs from the content provider to the ISPs 124 o The caches would need to be able to cache data from all p2p 125 applications and consequently become complicated to deploy and 126 maintain over time as p2p application evolve 128 o The use of caches opens up the issue of storage of copyrighted 129 content 131 Thus, a solution is needed that can allow for peer selection by the 132 p2p application themselves that is friendly to the ISP's network 133 costs while being friendly to the applications' objective of good 134 performance for the user. 136 Recent studies [4], [5], [6] have suggested that it may be possible 137 to reduce the impact that P2P applications have on ISPs traffic 138 costs. This is mainly achieved by informed peer selection in the P2P 139 applications guided by network level metrics instead of random 140 selection. However, p2p applications do not have a trust 141 relationship with network operators and what may be good for the ISP 142 is not necessarily good for the performance of the p2p applications. 143 These competing interests necessitate a solution for ALTO that 144 addresses the interests of both the entities in the system. 146 This document describes the problem of optimizing traffic generated 147 by P2P applications using information provided by third parties, i.e. 148 the other peers in the network or the network operator. The overall 149 goal of optimizing the P2P application is for them to become more 150 network-friendly, while at the same time allowing the networks to 151 remain application-friendly. The following are key arguments that we 152 put forth in this draft: 154 o The problem of peer selection needs to take into account the 155 interests of the ISPs, application providers and the peers. The 156 goal should be to reduce the impact on ISP without sacrificing the 157 performance of p2p applications. There are many situations we 158 elaborate upon in Section 3 where simply considering ISP interests 159 leads to poor performance for p2p applications. Information about 160 peer connectivity characteristics is an important component of the 161 ALTO problem of peer selection (in conjunction with ISP routing 162 information) and together with network topology information, can 163 enable peers to optimize their performance as well as take into 164 account ISP interests. 166 o An ALTO system with information about ISP routing alone does not 167 provide enough incentives for adoption in p2p applications, due to 168 the competing interests of the two parties and the lack of trust. 169 Combining both elements of peer selection creates an incentive for 170 p2p applications to actually use the ALTO service. 172 o Application-specific solutions for sharing peer connectivity 173 characteristics are inefficient and cause unnecessary overhead in 174 the network. A common information plane allows reuse of such 175 information across a wide range of applications ranging from DHT 176 next hop selection, multi-source file download, relay selection, 177 mirror selection, etc., since many of the connectivity 178 characteristics of peers such as upload/download bandwidth, 179 network coordinate, wireless link information are useful to a 180 multitude of p2p applications in peer selection. 182 The rest of this draft is structured as follows. Section 3 183 introduces the problem and argues for the multiple criterion that 184 need to be considered when developing solutions, while Section 4 185 describes the design goals of the system. 187 2. Terminology 189 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 190 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 191 document are to be interpreted as described in RFC 2119 [1]. 193 3. Problem Statement 195 Bulk data applications are posing serious challenges to the Internet 196 infrastructure and more mass adoption of such applications would only 197 increase that challenge. P2P bulk data applications and other large 198 volume HTTP traffic such as video currently dominate the Internet 199 traffic. These applications do not generally benefit from the 200 traffic engineering techniques developed for the Internet. In the 201 HTTP traffic case, the traffic optimization issues are often 202 addressed using the CDN infrastructure. For P2P bulk data 203 applications, the problem is about picking the right peers to 204 communicate with and the criteria for doing this vary greatly based 205 on the application. Hence, intelligent peer selection is the 206 fundamental problem to address for these applications. 208 One necessary input for intelligent peer selection has been shown to 209 be network topology information. And, accurate network topology 210 information can only be obtained with the help of ISPs. However, 211 there is more to peer selection than just network topology 212 information. 214 Consider a Client Application at node A which wants to access a 215 service for peer selection such as ALTO. Overall peer selection in 216 ALTO can be performed using two sets of information: (1) One set of 217 information is that from the network, i.e. network-assisted ALTO 218 which promotes peer selection that is beneficial to the ISP by either 219 reducing the interdomain traffic or reducing congestion on bottleneck 220 links inside the ISP. (2) The other set of information is from the 221 set of potential Client Application Providers are targets for peer 222 connectivity, i.e. peer-assisted ALTO. 224 3.1. Network-assisted ALTO 226 Network-assisted application layer traffic optimization refers to the 227 use of network operators in guiding peer selection for p2p 228 applications. Network operators can use network topology and traffic 229 statistics to provide hints to the P2P applications on which hosts it 230 would prefer the application pick for data transfer. For example, 231 peers that involve inter-domain routing would be given lower priority 232 in the response to the querying P2P application. Another example 233 would be that peers whose connectivity is such that their choice 234 would increase the congestion on an already congested link inside the 235 ISP. Such peers would also be given lower priority. Some recent 236 work has proposed solutions in this space [5],[4]. 238 3.2. Peer-assisted ALTO 240 Peer-assisted application layer traffic optimization refers to the 241 use of published information about peers and their connectivity to 242 the Internet in guiding peer selection for p2p applications. For 243 example, BitTorrent-like data transfer applications would query 244 metrics related to the peer of interest to decide on the peers to 245 select for initial data transfer. This information could be for 246 example the upload bandwidth of the peer. These choices could then 247 be refined or changed by monitoring data connections. Another 248 example would be for VoIP applications to query the ALTO service for 249 peers that it wants to use as relays to find one with low latency. 250 Altough latency information is pairwise the peer could publish its 251 network coordinate calculated by a system such as GNP (Global Network 252 Positioning) into the ALTO service which could then be retrieved and 253 used by a querying peer to estimate network latency. Publishing peer 254 connectivity could also involve edge-specific information such as 255 which cell id a peer is connected to in a cellular network so that 256 another peer in the same cell is discouraged from making a connection 257 within the same cell to minimize the congestion and avoid occuping 2 258 downlink and 2 uplink channels in the same cell. This type of 259 traffic optimization cannot be acheived via network-assisted ALTO. 261 3.3. The need for multiple criterion 263 This section justifies the need for multiple criterion in ALTO: i.e. 264 the need for both ISP related information and peer related 265 information. Note that the underlying assumption is that peers and 266 ISPs may not necessarily trust each other and thus any solution in 267 this space needs to consider the interests of both parties. 269 3.3.1. Peer-assisted ALTO alone 271 It is already well known that using peer related information alone is 272 not enough. Simply randomly selecting peers and trying them out and 273 reevaluating the choices based on observed performance is suboptimal 274 as it takes time to converge on a good set of peers as well as causes 275 unnecessary overhead in the network. Incorporating locality into 276 peer selection using either active measurements or some sort of 277 information plane (e.g. [7]) has been shown to improve the download 278 completion time performance of BitTorrent. For example, [7] showed a 279 35% reduction in download time for 60% of the peers in a swarm. 280 Other studies [5] showed this gain to be around 10-25%. However, [5] 281 also showed that such an approach increases the traffic on congestion 282 on bottleneck links by 69%. In summary, while peer related 283 information is powerful in improving performance, it affects ISP 284 performance and can lead to shaping and throttling. 286 3.3.2. Network-assisted ALTO alone 288 On the other hand there are several situations where relying on ISP 289 information by itself is not sufficient. If ISPs simply return a 290 rank ordered list of node identifiers in response to a list of node 291 identifiers sent in a query, the querying node may not be optimizing 292 its performance. It is possible that the peers in a swarm that are 293 within the ISP are all DSL hosts which can upload at 128Kbps while 294 some of the other peers that may involve interdomain routing are 295 actually high bandwidth fiber or cable connected hosts with high 296 upload bandwidth. In such cases, the p2p application user would 297 sustain high download times to meet the ISP's objective. Similarly, 298 peers that are nearby geographically (which is correlated with 299 latency typically) may be preferred for relays in VoIP but do not 300 meet the ISP's objective since they use a different access network. 302 The reasons for these problems are two-fold: (1) The ISPs' objectives 303 in general may not always match the users objective of improved 304 performance, and (2) The ISP can only provide an indication of its 305 preference for connectivity to certain peers outside its domain but 306 it does not have any notion of end-to-end performance provided by 307 these outside peers. 309 Thus neither network-asissted ALTO or peer-assisted ALTO alone help 310 in bringing together these competing interests together. Thus, in 311 this draft we argue for a combined solution that provides a true 312 information plane for peer selection, i.e. one that does not 313 sacrifice but, in fact improves the performance of p2p applications 314 while getting cooperation from p2p applications for the ISP. ISP 315 information is only one of the two pillars of the ALTO service - it 316 is an important one, given that the ISPs have knowledge of internal 317 congestion, interdomain peering policies and connectivity 318 information. Peer information is the other pillar of the ALTO 319 service; and by providing it as a service to all p2p applications we 320 reduce the overhead and inefficiency of each application performing 321 their own measurements which is inefficient for the network and 322 complicated for application developers. 324 3.4. Applicability and Discussion 326 The problem of peer selection has been studied at various dimensions 327 and has pretty broad applicability. At the very basic level, 328 intelligent peer selection can be applied, in file sharing networks, 329 to the problem of choosing the right source to download a file from. 330 However, there are a variety of other applications for such 331 intelligent peer selection. For example, locality aware structured 332 overlays are built with topology-assisted neighbor selection models 333 or topology-based identity generation shcemes. The more accurate the 334 topology information is, the more efficient such schemes will be. 335 Very fundamentally, intelligent neighbor selection schemes aim at 336 improving the query latency in such systems. Peer selection is also 337 applicable to other problems such as identifying the best super peer 338 to contact in a system, using the best relay for NAT traversal, 339 identifying the best next hop for a query based on several criteria 340 (e.g., quality, reputation, semantic expertise, etc.), etc. 342 A lot of study has been done on the applicability of the peer 343 selection problem. Some examples include [8], [9], [10], [11], [12], 344 [13]. 346 Two observations can be made from these applicability aspects of peer 347 selection. One is that the problem is applicable to a wide range of 348 scenarios with some possible generalization - in all cases, while the 349 criteria for peer selection and the context in which it is done may 350 be different, the basic model for peer selection revolves around 351 ranking a list of peers based on information collected about the 352 peers in accordance with the given criteria. A second observation is 353 that the same piece of information collected could be put to use in 354 very different ways in different scenarios - e.g., the use of 355 topology information in determining source peers to download content 356 from and neighbor peers to make connections with are very different 357 applications. 359 Peer selection is also equally important for application providers, 360 ISPs and the peers themselves for very different reasons. ISPs have 361 an incentive to keep their operational costs to a minimum, while 362 ensuring their customers a good experience. Application providers 363 are interested in keeping their own operational costs to a minimum, 364 which by nature, conflicts with the ISP's interests of keeping the 365 costs low. Application providers are also interested in ensuring 366 that the application performs well to keep the peers interested in 367 the application. For the peers themselves, the emphasis is on 368 performance as well as their own access costs. 370 The varied scenarios of applicability of peer selection information, 371 the diverse interests of various parties in peer selection and the 372 underlying common nature of these models suggest that the problem 373 should be tackled in a uniform manner, allowing for generality and 374 extensibility of information. The scenarios also broadly fall under 375 two buckets - one, where information may be obtained from specific 376 hosts (e.g., ISP hosts, reputation tracking servers, etc.) and 377 another, where information may be obtained from any number of peers. 378 The final peer selection algorithm may be a combination of various 379 pieces of such information in a manner that fits a given scenario and 380 criterion. Solving any one piece of this puzzle separately is likely 381 to lead to multiple different protocols and mechanisms for the same 382 problem. Further, any one such protocol is unlikely to result in a 383 dramatic improvement of the scenario (be it bandwidth utilization or 384 latency reduction, etc.). For instance, as argued earlier in this 385 draft, network-assistance and peer information are both important to 386 consider for peer selection. Hence, the adoption of any one of these 387 protocols will be less incentivized in such a fragmented model. 389 The ALTO service, given a set of host location identifiers for peers, 390 may annotate them with ISP information (such as the p-distance from 391 P4P) as well as peer connectivity information (which is variable and 392 could be related to bandwidth, network coordinates, wireless link 393 information etc ) and return the annotated set to the p2p 394 application. The p2p application can use this data to perform peer 395 selection based on its requirements. We argue that the peer 396 connectivity information be a generic container that can contain 397 different types of information. However the request response 398 protocol can be unified as an ALTO protocol for retrieving the 399 annotated information for each destination peer. Note that the data 400 pertaining peer-assisted ALTO and network-assisted ALTO may be stored 401 differently but the interface to p2p applications can be kept 402 consistent. 404 4. Design Goals 406 The fundamental goal of ALTO, extracting from what has been described 407 thus far, has to do with allowing the use of both network-assisted 408 and peer-assisted information exchanges for various categories of 409 applications that can use it. The main idea is to model ALTO as a 410 service that these applications may use to apply the peer selection 411 intelligence in the specific context of interest to the application. 412 The following are design goals for the ALTO service framework: 414 1. The ALTO service should accommodate specific hosts providing 415 network topology information. 417 Network topology information may be provided by hosts in an 418 ISP network with much greater accuracy than can be done via 419 other schemes. Hence, a model that allows for such 420 information exchange from specific hosts is useful. The 421 discovery of such hosts capable of providing this information 422 falls in this territory as well. 424 2. The ALTO service should allow peers to publish ALTO related 425 information in an application agnostic manner. 427 Peers may publish information of various kinds that helps in 428 peer selection. A primary example of such information is the 429 connectivity characteristics of a peer. This type of 430 information allows other criteria to be taken into account for 431 peer selection, such as the uplink/downlink bandwidth of 432 peers, the wireless nature of links, etc. This information, 433 coupled with topology or proximity information, will allow 434 exchange of bulk data in a manner that benefits the ISPs and 435 the peers. 437 3. The ALTO service should allow for both centralized and 438 distributed service models. 440 ISP hosts and any servers that are queried for ALTO related 441 information may be offering the ALTO service in a centralized 442 model. On the other hand, peer information related to ALTO 443 may be obtained in a distributed fashion, e.g., by querying an 444 overlay. It is important to cater to both models and also 445 allow for the two models to be linked. For instance, a query 446 on an overlay for ALTO related information may result in a 447 different node on the overlay querying the ISP's ALTO host. 449 4. The ALTO protocols should be agnostic to the actual peer 450 selection algorithm in use. 452 The peer selection algorithm itself is contextual and depends 453 on different factors for different scenarios. For instance, 454 source selection for bulk data downloads involves optimal 455 bandwidth usage and performance as criteria, neighbor 456 selection in structured overlays may be a function of hop 457 count and delay, relay selection for NAT traversal may be a 458 function of the relay capacity and connectivity 459 characteristics and so on. Hence, the ALTO protocols should 460 be agnostic to the specific peer selection algorithm for any 461 given instantiation. 463 5. The ALTO protocols should be generic to allow any type of 464 information useful for performing ALTO services to be exchanged. 465 The ALTO protocols should be extensible to allow carrying new 466 types of information that may be defined at a future point. 468 As in the case of the algorithm, the types of information 469 exchanged for peer selection are also contextual to various 470 scenarios. For instance, bandwidth or latency based peer 471 selection may involve topology information and connectivity 472 characteristics of peers, relevance based peer selection may 473 involve the semantic expertise of various peers, and so on. 474 Hence, the ALTO protocols should simply be a container to 475 transport information that assists in peer selection without 476 being dependent on the actual type of information exchanged. 478 5. Security Considerations 480 Information exchange, as facilitated by ALTO, may be sensitive and 481 may require secure communication. Hence, the ALTO protocols must 482 provide for channel security properties such as confidentiality and 483 integrity protection. Further, the exchange of some of this 484 information may need to be limited to certain entities. This calls 485 for authentication and authorization of entities prior to exchange of 486 ALTO information. Hence, the ALTO framework should provide for 487 entity authentication and authorization as part of the service. When 488 various types of information to be carried in the ALTO protocols are 489 standardized, a call must be made about whether it is subject to the 490 authorization model. Further, some types of information exchanges 491 could lead to privacy issues to various parties and the implications 492 of that need to be studied prior to standardization. 494 6. IANA Considerations 496 This document does not have any IANA considerations. 498 7. Acknowledgments 500 This draft has benefited from the insights presented in several IETF 501 drafts namely the ALTO problem statement, requirements and survey 502 drafts. The research work done on IPlane, P4P, Taming the torrent, 503 and ISP and P2P oracles as well as the various measurement studies on 504 P2P applications impact on ISPs performed by the research community 505 have helped inform us in creating this draft. 507 8. References 509 8.1. Normative References 511 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 512 Levels", BCP 14, RFC 2119, March 1997. 514 8.2. Informative References 516 [2] Karagiannis, T., Rodriguez, P., and K. Papagiannaki, "Should 517 ISPs fear Peer-Assisted Content Distribution?", IMC Proceedings 518 of the Internet Measurement Conference, 2005. 520 [3] Akella, A., Seshan, S., and A. Shaikh, "An Empirical Evaluation 521 of WideArea Internet Bottlenecks", Proceedings of ACM SIGCOMM, 522 2003. 524 [4] Aggarwal, V., Feldmann, A., and C. Scheideler, "Can ISPs and 525 P2P systems co-operate for improved performance?", ACM SIGCOMM 526 Computer Communications Review (CCR), 37:3, pp. 29-40, 2006. 528 [5] Xie, H., Krishnamurthy, A., Silberschatz, A., and R. Yang, 529 "P4P: Explicit Communications for Cooperative Control Between 530 P2P and Network Providers", Proceedings of ACM SIGCOMM, 2008. 532 [6] Choffnes, D. and F. Bustamante, "Taming the Torrent: A 533 practical approach to reducing cross-ISP traffic in P2P 534 systems", Proceedings of ACM SIGCOMM, 2008. 536 [7] Madhyastha, H., Isdal, T., Piatek, M., Dixon, C., Anderson, T., 537 Krishnamurthy, A., and A. Venkataramani, "iPlane: an 538 information plane for distributed services", Proceedings of 539 USENIX OSDI, 2006. 541 [8] Lo, V., Liu, Y., GauthierDickey, C., and J. Li, "Scalable 542 Leader Selection in Peer-to-Peer Overlay Networks", 543 Proceedings of Second International Workshop on Hot Topics in 544 Peer-to-Peer Systems (Hot-P2P), 2005. 546 [9] Xhafa, F., Barolli, L., Fernandez, R., and T. Daradoumis, "An 547 Experimental Study on Peer Selection in a P2P Network over 548 PlanetLab", Proceedings of International Conference on 549 Parallel Processing Workshops, 2007. 551 [10] Yang, X. and G. Veciana, "Service Capacity of Peer to Peer 552 Networks", Proceedings of IEEE INFOCOM, 2004. 554 [11] Habib, A. and J. Chuang, "Service Differentiated Peer 555 Selection: An Incentive Mechanism for Peer-to-Peer Media 556 Streaming", Proceedings of IWQoS, 2004. 558 [12] Tang, S., Wang, H., and P. Meigham, "The Effect of Peer 559 Selection with Hopcount or Delay Constraint on Peer-to-Peer 560 Networking", Proceedings of IFIP NETWORKING, 2008. 562 [13] Haas, P. and R. Siebes, "Peer Selection in PeertoPeer Networks 563 with Semantic Topologies", Proceedings of WWW, 2004. 565 Authors' Addresses 567 Saumitra M. Das 568 Qualcomm, Inc. 569 3195 Kifer Road 570 Santa Clara, CA 571 USA 573 Phone: +1 408-533-9529 574 Email: saumitra@qualcomm.com 576 Vidya Narayanan 577 Qualcomm, Inc. 578 5775 Morehouse Dr 579 San Diego, CA 580 USA 582 Phone: +1 858-845-2483 583 Email: vidyan@qualcomm.com 585 Lakshminath Dondeti 586 Qualcomm, Inc. 587 5775 Morehouse Dr 588 San Diego, CA 589 USA 591 Phone: +1 858-845-1267 592 Email: ldondeti@qualcomm.com 594 Full Copyright Statement 596 Copyright (C) The IETF Trust (2008). 598 This document is subject to the rights, licenses and restrictions 599 contained in BCP 78, and except as set forth therein, the authors 600 retain all their rights. 602 This document and the information contained herein are provided on an 603 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 604 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 605 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 606 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 607 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 608 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 610 Intellectual Property 612 The IETF takes no position regarding the validity or scope of any 613 Intellectual Property Rights or other rights that might be claimed to 614 pertain to the implementation or use of the technology described in 615 this document or the extent to which any license under such rights 616 might or might not be available; nor does it represent that it has 617 made any independent effort to identify any such rights. Information 618 on the procedures with respect to rights in RFC documents can be 619 found in BCP 78 and BCP 79. 621 Copies of IPR disclosures made to the IETF Secretariat and any 622 assurances of licenses to be made available, or the result of an 623 attempt made to obtain a general license or permission for the use of 624 such proprietary rights by implementers or users of this 625 specification can be obtained from the IETF on-line IPR repository at 626 http://www.ietf.org/ipr. 628 The IETF invites any interested party to bring to its attention any 629 copyrights, patents or patent applications, or other proprietary 630 rights that may cover technology that may be required to implement 631 this standard. Please address the information to the IETF at 632 ietf-ipr@ietf.org.