idnits 2.17.1 draft-ietf-alto-problem-statement-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 and authors Copyright Line does not match the current year -- The document date (September 18, 2009) is 5305 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-16) exists of draft-ietf-alto-reqs-00 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Seedorf 3 Internet-Draft NEC 4 Intended status: Informational E. Burger 5 Expires: March 22, 2010 Neustar Inc. 6 September 18, 2009 8 Application-Layer Traffic Optimization (ALTO) Problem Statement 9 draft-ietf-alto-problem-statement-04 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on March 22, 2010. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 Distributed applications -- such as file sharing, real-time 48 communication, and live and on-demand media streaming -- prevalent on 49 the Internet use a significant amount of network resources. Such 50 applications often transfer large amounts of data through connections 51 established between nodes distributed across the Internet with little 52 knowledge of the underlying network topology. Some applications are 53 so designed that they choose a random subset of peers from a larger 54 set to exchange data with. Absence any topology information guiding 55 such choices, or acting on sub-optimal or local information obtained 56 from measurements and statistics, these applications often make less 57 than desirable choices. 59 This document discusses issues related to an information-sharing 60 service that enables applications to perform better-than-random peer 61 selection. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.2. State-of-the-Art . . . . . . . . . . . . . . . . . . . . . 4 68 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3. The Problem . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 4.1. File sharing . . . . . . . . . . . . . . . . . . . . . . . 8 72 4.2. Cache/Mirror Selection . . . . . . . . . . . . . . . . . . 8 73 4.3. Live Media Streaming . . . . . . . . . . . . . . . . . . . 8 74 4.4. Realtime Communications . . . . . . . . . . . . . . . . . 9 75 4.5. Distributed Hash Tables . . . . . . . . . . . . . . . . . 9 76 5. Aspects of the Problem . . . . . . . . . . . . . . . . . . . . 9 77 5.1. Information provided by an ALTO service . . . . . . . . . 9 78 5.2. ALTO Service Providers . . . . . . . . . . . . . . . . . . 10 79 5.3. ALTO Service Implementation . . . . . . . . . . . . . . . 10 80 5.4. User Privacy . . . . . . . . . . . . . . . . . . . . . . . 10 81 5.5. Topology Hiding . . . . . . . . . . . . . . . . . . . . . 11 82 5.6. Coexistence with Caching . . . . . . . . . . . . . . . . . 11 83 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 84 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 85 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 12 86 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 87 10. Informative References . . . . . . . . . . . . . . . . . . . . 13 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 90 1. Introduction 92 1.1. Overview 94 Distributed applications, both peer-to-peer (P2P) and client/server 95 used for file sharing, real-time communication, and live and on- 96 demand media streaming, use a significant amount of network capacity 97 and CPU cycles in the routers [WWW.wired.fuel]. In contrast to 98 centralized applications, distributed applications access resources 99 such as files or media relays distributed across the Internet and 100 exchange large amounts of data in connections that they establish 101 directly with nodes sharing such resources. 103 One advantage of highly distributed systems results from the fact 104 that the resources such systems offer are often available through 105 multiple replicas. However, applications generally do not have 106 reliable information of the underlying network and thus have to 107 select among the available peers that provide such replicas randomly 108 or based on information they deduce from partial observations that, 109 in some situations, lead to suboptimal choices. For example, one 110 peer selection algorithm is based only on the measurements during 111 initial connection establishment between two peers. Since actual 112 data transmission does not begin, the algorithm measures only the 113 round-trip time and cannot reliably deduce actual throughput between 114 the peers. Thus, such a peer selection algorithm that simply uses 115 round-trip time may result in a sub-optimal choice of peers. 117 Many of today's P2P systems use an overlay network consisting of 118 direct peer connections. Such connections often do not account for 119 the underlying network topology. In addition to having suboptimal 120 performance, such networks can lead to congestion and cause serious 121 inefficiencies. As shown in [ACM.fear], traffic generated by popular 122 P2P applications often cross network boundaries multiple times, 123 overloading links that are frequently subject to congestion 124 [ACM.bottleneck]. Moreover, such transits, besides resulting in a 125 poor experience for the user, can be quite costly to the network 126 operator. 128 Recent studies [ACM.ispp2p] [WWW.p4p.overview] [ACM.ono] show a 129 possible solution to this problem. Internet Service Providers (ISP), 130 network operators or third parties can collect more reliable network 131 information. This information includes relevant information such as 132 topology or link capacity. Normally, such information changes on a 133 much longer time scale than information used for congestion control 134 on the transport layer. Providing this information to P2P 135 applications can enable them to apply better-than-random peer 136 selection with respect to the underlying network topology. As a 137 result, it may be possible to increase application performance, 138 reduce congestion and decrease the overall amount of traffic across 139 different networks. Presumably, both applications and the network 140 operator can benefit from such information. Thus, network operators 141 have an incentive to provide, either directly themselves or 142 indirectly through a third party, such information; applications have 143 an incentive to use such information. This document discusses issues 144 related to an information-sharing service that enables applications 145 to perform better-than-random peer selection. 147 Section 2 provides definitions. Section 3 introduces the problem. 148 Section 4 describes some use cases where both P2P applications and 149 network operators benefit from a solution to such a problem. 150 Section 5 describes the main issues to consider when designing such a 151 solution. Note a companion document to this document, the ALTO 152 Requirements [I-D.ietf-alto-reqs], goes into the details of these 153 issues. 155 1.2. State-of-the-Art 157 The papers [ACM.ispp2p], [I-D.bonaventure-informed-path-selection] 158 and [WWW.p4p.overview] present examples of contemporary solution 159 proposals that address the problem described in this document. 160 Moreover, these proposals have encouraging simulation and field test 161 results. These and similar, independent, solutions all consist of 162 two essential parts: 163 o a discovery mechanism that a P2P application uses to find a 164 reliable information source and 165 o a protocol P2P applications use to query such sources in order to 166 retrieve the information needed to perform better-than-random 167 selection of the endpoints providing a desired resource. 169 It is not clear how such solutions will perform if deployed globally 170 on the Internet. However, wide adoption is unlikely without an 171 agreement on a common solution based upon an open standard. 173 2. Definitions 175 The following terms have special meaning in the definition of the 176 Application-Layer Traffic Optimization (ALTO) problem. 178 Application: A distributed communication system (e.g., file sharing) 179 that uses the ALTO service to improve its performance or quality 180 of experience while improving resource consumption in the 181 underlying network infrastructure. Applications may use the P2P 182 model to organize themselves, use the client-server model, or use 183 a hybrid of both (i.e., a mixture between the P2P model and the 184 client-server model). 186 Peer: A specific participant in an application. Colloquially, a 187 peer refers to a participant in a P2P network or system, and this 188 definition does not violate that assumption. If the basis of the 189 application is the client-server or hybrid model, then the usage 190 of the terms "client" and "server" disambiguates the peer's role. 191 P2P: Peer-to-Peer. 192 Resource: Content (such as a file or a chunk of a file), or a server 193 process (for example to relay a media stream or perform a 194 computation), which applications can access. In the ALTO context, 195 a resource is often available in several equivalent replicas. In 196 addition, different peers share these resources, often 197 simultaneously. 198 Resource Identifier: An application layer identifier used to 199 identify a resource, no matter how many replicas exist. 200 Resource Provider: For P2P applications, a resource provider is a 201 specific peer that provides some resources. For client-server or 202 hybrid applications, a provider is a server that hosts a resource. 203 Resource Consumer: For P2P applications, a resource consumer is a 204 specific peer that needs to access resources. For client-server 205 or hybrid applications, a consumer is a client that needs to 206 access resources. 207 Transport Address: All address information that a resource consumer 208 needs to access the desired resource at a specific resource 209 provider. This information usually consists of the resource 210 provider's IP address and possibly other information, such as a 211 transport protocol identifier or port numbers. 212 Overlay Network: A virtual network consisting of direct connections 213 on top of another network, established by a group of peers. 214 Resource Directory: An entity that is logically separate from the 215 resource consumer that assists a resource consumer to identify a 216 set of resource providers. Some P2P applications refer to the 217 resource directory as a P2P tracker. 218 ALTO Service: Several resource providers may be able to provide the 219 same resource. The ALTO service gives guidance to a resource 220 consumer and/or resource directory about which resource 221 provider(s) to select in order to optimize the client's 222 performance or quality of experience while improving resource 223 consumption in the underlying network infrastructure. 224 ALTO Server: A logical entity that provides interfaces to the 225 queries to the ALTO service. 226 ALTO Client: The logical entity that sends ALTO queries. Depending 227 on the architecture of the application one may embed it in the 228 resource consumer and/or in the resource directory. 229 ALTO Query: A message sent from an ALTO client to an ALTO server, 230 which requests guidance from the ALTO Service. 232 ALTO Response: A message that contains guiding information from the 233 ALTO service as a reply to an ALTO query. 234 ALTO Transaction: An ALTO transaction consists of an ALTO query and 235 the corresponding ALTO response. 236 Local Traffic: Traffic that stays within the network infrastructure 237 of one Internet Service Provider (ISP). This type of traffic 238 usually results in the least cost for the ISP. 239 Peering Traffic: Internet traffic exchanged by two Internet Service 240 Providers whose networks connect directly. Apart from 241 infrastructure and operational costs, peering traffic is often 242 free to the ISPs, within the contract of a peering agreement. 243 Transit Traffic: Internet traffic exchanged on the basis of economic 244 agreements amongst Internet Service Providers (ISP). An ISP 245 generally pays a transit provider for the delivery of traffic 246 flowing between its network and remote networks to which the ISP 247 does not have a direct connection. 248 Application Protocol: A protocol used by the application for 249 establishing an overlay network between the peers and exchanging 250 data on it, as well as for data exchange between peers and 251 resource directories if applicable. These protocols play an 252 important role in the overall ALTO architecture. However, 253 defining them is out of the scope of the ALTO WG. 254 ALTO Client Protocol: The protocol used for sending ALTO queries and 255 ALTO replies between an ALTO client and ALTO Server. 256 Provisioning Protocol: A protocol used for populating the ALTO 257 server with information. 259 +------+ 260 +-----+ | Peers 261 +-----+ +------+ +=====| |-*-+ 262 | |.......| |====+ +-*-*-+ * 263 +-----+ +------+ | * ***** 264 Source of ALTO | * 265 Information Server | +-*---+ 266 +=====| | Resource Directory 267 +-----+ (Tracker, proxy) 268 Legend: 269 === ALTO client protocol 270 *** Application protocol (out of scope) 271 ... Provisioning or initialization (out of scope) 273 Overview of protocol interaction between ALTO elements 275 Figure 1 shows the scope of the ALTO client protocol: Peers or 276 resource directories can use such a protocol as ALTO-clients to query 277 an ALTO-server. The mapping of topological information onto an ALTO 278 service as well as the application protocol interaction between peers 279 and resource directories are out of scope for the ALTO client 280 protocol. 282 3. The Problem 284 Network engineers have been facing the problem of traffic 285 optimization for a long time and have designed mechanisms like MPLS 286 [RFC3031] and DiffServ [RFC3260] to deal with it. The problem these 287 protocols address consists in finding (or setting) optimal routes (or 288 optimal queues in routers) for packets traveling between specific 289 source and destination addresses and based on requirements such as 290 low latency, high reliability, and priority. Such solutions are 291 usually implemented at the link and network layers, and tend to be 292 almost transparent. 294 However, distributed applications in general and bandwidth-greedy P2P 295 applications used for example for file-sharing in particular, cannot 296 directly use the aforementioned techniques. By cooperating with 297 external services that are aware of the network topology, 298 applications could greatly improve the traffic they generate. In 299 fact, when a P2P application needs to establish a connection, the 300 logical target is not a stable host, but rather a resource (e.g., a 301 file or a media relay) that can be available in multiple instances on 302 different peers. Selection of a good host from an overlay 303 topological proximity has a large impact on the overall traffic 304 generated. 306 Note that while traffic considerations are important, several 307 other factors also play a role on the performance experienced by 308 users of distributed applications. These include the need to 309 avoid overloading individual nodes, fetching rare pieces of a file 310 before those pieces available at a multiplicity of nodes, and so 311 on. However, better information about topological conditions does 312 improve the overall selection algorithm on an important aspect. 314 Better-than-random peer selection is helpful in the initial phase of 315 the process. Consider a P2P protocol in which a querying peer 316 receives a list of candidate destinations where a resource resides. 317 From this list, the peer will derive a smaller set of candidates to 318 connect to and exchange information with. In another example, a 319 streaming video client may be provided with a list of destinations 320 from which it can stream content. In both cases, the use of topology 321 information in an early stage will allow applications to improve 322 their performance and will help ISPs make a better use of their 323 network resources. In particular, an economic goal for ISPs is to 324 reduce the transit traffic on interdomain links. 326 Addressing the Application-Layer Traffic Optimization (ALTO) problem 327 means, on the one hand, deploying an ALTO service to provide 328 applications with information regarding the underlying network and, 329 on the other hand, enhancing applications in order to use such 330 information to perform better-than-random selection of the endpoints 331 they establish connections with. 333 4. Use Cases 335 4.1. File sharing 337 File sharing applications allow users to search for content shared by 338 other users and to download respective resources from other users. 339 For instance, search results can consist of many instances of the 340 same file (or chunk of a file) available from multiple sources. The 341 goal of an ALTO solution is to help peers find the best ones 342 according to the underlying networks. 344 On the application side, integration of ALTO functionalities may 345 happen at different levels. For example, in the completely 346 decentralized Gnutella network, selection of the best sources is 347 totally up to the user. In systems like BitTorrent and eDonkey, 348 central elements such as trackers or servers act as mediators. 349 Therefore, in the former case, improvement would require modification 350 in the applications, while in the latter it could just be implemented 351 in some central elements. 353 4.2. Cache/Mirror Selection 355 Providers of popular content like media and software repositories 356 usually resort to geographically distributed caches and mirrors for 357 load balancing. Selection of the proper mirror/cache for a given 358 user is today based on inaccurate geolocation data, on proprietary 359 network location systems or often delegated to the user herself. An 360 ALTO solution could be easily adopted to ease such a selection in an 361 automated way. 363 4.3. Live Media Streaming 365 P2P applications for live streaming allow users to receive multimedia 366 content produced by one source and targeted to multiple destinations, 367 in a real-time or near-real-time way. This is particularly important 368 for users or networks that do not support multicast. Peers often 369 participate in the distribution of the content, acting as both 370 receivers and senders. The goal of an ALTO solution is to help a 371 peer to find effective communicating peers that exchange the media 372 content. 374 4.4. Realtime Communications 376 P2P real-time communications allow users to establish direct media 377 flows for real-time audio, video, and real-time text calls or to have 378 text chats. In the basic case, media flows directly between the two 379 endpoints. However, unfortunately a significant portion of users 380 have limited access to the Internet due to NATs, firewalls or 381 proxies. Thus, other elements need to relay the media. Such media 382 relays are distributed over the Internet with a public addresses. An 383 ALTO solution needs to help peers to find the best relays. 385 4.5. Distributed Hash Tables 387 Distributed hash tables (DHT) are a class of overlay algorithms used 388 to implement lookup functionalities in popular P2P systems, without 389 using centralized elements. In such systems, a peer maintains the 390 addresses of a set of other peers participating in the same DHT in a 391 routing table, sorted according to specific criteria. An ALTO 392 solution can provide valuable information for DHT algorithms. 394 5. Aspects of the Problem 396 This section introduces some aspects of the problem that some people 397 may not be aware of when they first start studying the problem space. 399 5.1. Information provided by an ALTO service 401 The goal of an ALTO service is to provide applications with 402 information they can use to perform better-than-random peer 403 selection. In principle, there are many types of information that 404 can help applications in peer selection. However, not all of the 405 information to be conveyed is amenable to an ALTO-like service. More 406 specifically, information that can change very rapidly such as 407 transport layer congestion is out of scope for an ALTO service. Such 408 information is better suited to be transferred through an in-band 409 technique at the transport layer instead of an ALTO-like out-of-band 410 technique at the application layer. An ALTO solution for congestion 411 will either have outdated information, or must be contacted too 412 frequently by applications. And finally, information such as end-to- 413 end delay and available bandwidth can be more accurately measured by 414 applications themselves. 416 The kind of information that is meaningful to convey to applications 417 via an out-of-band ALTO service is any information that applications 418 cannot easily obtain themselves and which changes on a much longer 419 time scale than the instantaneous information used for congestion 420 control on the transport layer. Examples for such information are 421 operator's policies, geographical location or network proximity 422 (e.g., the topological distance between two peers), the transmission 423 costs associated with sending/receiving a certain amount of data to/ 424 from a peer, or the remaining amount of traffic allowed by a peer's 425 operator (e.g., in case of quotas or limited flat-rate pricing 426 models). 428 5.2. ALTO Service Providers 430 At least three different kinds of entities can provide ALTO services: 431 1. Network operators. Network operators usually have full knowledge 432 of the network they administer and are aware of their network 433 topology and policies. 434 2. Third parties. Third parties are entities separate from network 435 operators, but which may have either collected network 436 information or have arrangements with network operators to learn 437 the network information. Examples of such entities are content 438 delivery networks like Akamai, which control wide and highly 439 distributed infrastructures, or companies providing an ALTO 440 service on behalf of ISPs. 441 3. User communities. User communities run distributed algorithms, 442 for example for estimating the topology of the Internet. 444 5.3. ALTO Service Implementation 446 It is important for the reader to understand there are significant 447 user communities that expect an ALTO Server to be a centralized 448 service. Likewise, there are other user communities to expect that 449 the ALTO service be a distributed service, possibly even based on or 450 integrating with a P2P service. 452 A result of this is one can reasonably expect there to be some sort 453 of service discovery mechanism to go along with the ALTO protocol 454 definition. 456 5.4. User Privacy 458 On the one hand, there are data elements an ALTO client could provide 459 in its query to an ALTO server that could help increase the level of 460 accuracy in the replies. For example, if the querying client 461 indicates what kind of application it is using (e.g. real-time 462 communications or bulk data transfer), the server will be able to 463 indicate priorities in its replies accommodating the requirements of 464 the traffic the application will generate. On the other hand, 465 applications might consider such information private. In addition, 466 some applications may not know a priori what kind of request they 467 will be making. 469 5.5. Topology Hiding 471 Operators, with their intimate knowledge of their network topology, 472 can play an important role in addressing the ALTO problem. However, 473 operators often consider revealing details of such network 474 information to be confidential. 476 5.6. Coexistence with Caching 478 Caching is an approach to improving traffic generated by applications 479 that require large amounts of data transfers. In some cases, such 480 techniques have proven to be extremely effective in both enhancing 481 user experience and saving network resources. 483 A cache, either explicitly or transparently, replaces the content 484 source. Thus, a cache must in principle use and support the same 485 protocol as the querying peer. That is, if a cache stores web 486 content, it must present an HTTP interface to the web client. Any 487 cache solution for a given protocol needs to present that same 488 protocol to the client. Said differently, each caching solution for 489 a different protocol needs to implement that specific protocol. For 490 this reason, one can only reasonably expect caching solutions for the 491 most popular protocols, such as HTTP and BitTorrent. 493 It is extremely important to realize that caching and ALTO are 494 entirely orthogonal. ALTO, especially if it is aware of caches, can 495 in fact direct clients to nearby caches where the user could get a 496 much better quality of experience. 498 6. Security Considerations 500 This document is neither a requirements document nor a protocol 501 specification. However, we believe it is important for the reader to 502 understand areas of security and privacy that will be important for 503 the design and implementation of an ALTO solution. Moreover, issues 504 such as digital rights management are out of scope for ALTO, as they 505 are not technically enforceable at this level. 507 Some environments and use cases of ALTO may require client or server 508 authentication before providing sensitive information. In order to 509 support those environments interoperably, ALTO requirements 510 [I-D.ietf-alto-reqs] outlines minimum-to-implement authentication and 511 other security requirements. 513 Applications can decide to rely on information provided by an ALTO 514 server to enhance the peer selection process. In principle, this 515 enables the ALTO service that provides such information to influence 516 the behavior of the application, basically letting a third-party -- 517 the ALTO service provider -- take an important role in a distributed 518 system it was not previously involved in. 520 For example, in the case of an ALTO server deployed and run by an 521 ISP, the P2P community might consider it hostile because the operator 522 could: 523 o use ALTO to prevent content distribution and enforce copyrights; 524 o redirect applications to corrupted mediators providing malicious 525 content; 526 o track connections to perform content inspection or logging; 527 o apply policies based on criteria other than network efficiency. 528 For example, the service provider may suggest routes sub-optimal 529 from the user's perspective to avoid peering points regulated by 530 inconvenient economic agreements. 532 It is important to note there is no protocol mechanism to require 533 ALTO for P2P applications. If, for some reason, ALTO fails to 534 improve the performance of P2P applications, ALTO will not gain 535 popularity and the P2P community will not use it. 537 At the time of this writing, the privacy issues described in the 538 previous section are relevant for an ALTO solution. Users may be 539 reluctant to disclose sensitive information to an ALTO server. 540 Operators, on the other hand, may not wish to disclose information 541 that would expose details of their interior topology. When exploring 542 the solution space in detail, one needs to consider these issues so 543 that an ALTO protocol does not presume mandatory information 544 disclosure, by either clients or servers. 546 7. IANA Considerations 548 None. 550 8. Contributors 552 The basis of this document is draft-marocco-alto-problem-statement, 553 written by Enrico Marocco and Vijay Gurbani. They continue to 554 provide significant edits and inputs to the current document editors. 556 9. Acknowledgments 558 Vinay Aggarwal and the P4P working group conducted the research work 559 done outside the IETF. Emil Ivov, Rohan Mahy, Anthony Bryan, 560 Stanislav Shalunov, Laird Popkin, Stefano Previdi, Reinaldo Penno, 561 Dimitri Papadimitriou, Sebastian Kiesel, Greg DePriest and many 562 others provided insightful discussions, specific comments and much 563 needed corrections. 565 Jan Seedorf and Sebastian Kiesel are partially supported by the NAPA- 566 WINE project (Network-Aware P2P-TV Application over Wise Networks, 567 http://www.napa-wine.org), a research project supported by the 568 European Commission under its 7th Framework Program (contract no. 569 214412). The views and conclusions contained herein are those of the 570 authors and should not be interpreted as necessarily representing the 571 official policies or endorsements, either expressed or implied, of 572 the NAPA-WINE project or the European Commission. 574 Thanks in particular to Richard Yang for several reviews. 576 10. Informative References 578 [ACM.bottleneck] 579 Akella, A., Seshan, S., and A. Shaikh, "An Empirical 580 Evaluation of WideArea Internet Bottlenecks", Proceedings 581 of ACM SIGCOMM, October 2003. 583 [ACM.fear] 584 Karagiannis, T., Rodriguez, P., and K. Papagiannaki, 585 "Should ISPs fear Peer-Assisted Content Distribution?", 586 In ACM USENIX IMC, Berkeley 2005. 588 [ACM.ispp2p] 589 Aggarwal, V., Feldmann, A., and C. Scheideler, "Can ISPs 590 and P2P systems co-operate for improved performance?", In 591 ACM SIGCOMM Computer Communications Review 592 (CCR), 37:3, pp. 29-40. 594 [ACM.ono] Choffnes, D. and F. Bustamante, "Taming the Torrent: A 595 practical approach to reducing cross-ISP traffic in P2P 596 systems", Proceedings of ACM SIGCOMM, August 2008. 598 [I-D.bonaventure-informed-path-selection] 599 Saucez, D. and B. Donnet, "The case for an informed path 600 selection service", 601 draft-bonaventure-informed-path-selection-00 (work in 602 progress), February 2008. 604 [I-D.ietf-alto-reqs] 605 Kiesel, S., Popkin, L., Previdi, S., Woundy, R., and Y. 606 Yang, "Application-Layer Traffic Optimization (ALTO) 607 Requirements", draft-ietf-alto-reqs-00 (work in progress), 608 April 2009. 610 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 611 Label Switching Architecture", RFC 3031, January 2001. 613 [RFC3260] Grossman, D., "New Terminology and Clarifications for 614 Diffserv", RFC 3260, April 2002. 616 [SIGCOMM.resprox] 617 Gummadi, K., Gummadi, R., Ratnasamy, S., Gribble, S., 618 Shenker, S., and I. Stoica, "The impact of DHT routing 619 geometry on resilience and proximity", Proceedings of ACM 620 SIGCOMM, August 2003. 622 [WWW.p4p.overview] 623 Xie, H., Krishnamurthy, A., Silberschatz, A., and R. Yang, 624 "P4P: Explicit Communications for Cooperative Control 625 Between P2P and Network Providers", 626 . 628 [WWW.wired.fuel] 629 Glasner, J., "P2P fuels global bandwidth binge", 630 . 632 Authors' Addresses 634 Jan Seedorf 635 NEC Laboratories Europe, NEC Europe Ltd. 636 Kurfuersten-Anlage 36 637 Heidelberg 69115 638 Germany 640 Phone: +49 (0) 6221 4342 221 641 Email: jan.seedorf@nw.neclab.eu 642 URI: http://www.nw.neclab.eu 643 Eric W. Burger 644 Neustar Inc. 645 New Hampshire 646 USA 648 Phone: 649 Fax: +1 530 267 7447 650 Email: eburger@standardstrack.com 651 URI: http://www.standardstrack.com