idnits 2.17.1 draft-marocco-alto-problem-statement-05.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.ii 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 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 (March 8, 2009) is 5529 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). 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: September 9, 2009 This Space for Sale 6 March 8, 2009 8 Application-Layer Traffic Optimization (ALTO) Problem Statement 9 draft-marocco-alto-problem-statement-05 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 September 9, 2009. 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 Peer-to-peer applications, such as file sharing, real-time 48 communication, and live media streaming, use a significant amount of 49 Internet resources. Such applications often transfer large amounts 50 of data in direct peer-to-peer connections. However, they usually 51 have little knowledge of the underlying network topology. As a 52 result, they may choose their peers based on measurements and 53 statistics that, in many situations, may lead to suboptimal choices. 54 This document describes problems related to optimizing traffic 55 generated by peer-to-peer applications and associated issues such 56 optimizations raise in the use of network-layer information. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Research or Engineering? . . . . . . . . . . . . . . . . . 4 62 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. The Problem . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 4.1. File sharing . . . . . . . . . . . . . . . . . . . . . . . 8 66 4.2. Cache/Mirror Selection . . . . . . . . . . . . . . . . . . 8 67 4.3. Live Media Streaming . . . . . . . . . . . . . . . . . . . 9 68 4.4. Realtime Communications . . . . . . . . . . . . . . . . . 9 69 4.5. Distributed Hash Tables . . . . . . . . . . . . . . . . . 9 70 5. The Problem in Detail . . . . . . . . . . . . . . . . . . . . 9 71 5.1. ALTO Service Providers . . . . . . . . . . . . . . . . . . 9 72 5.2. Discovery of ALTO servers . . . . . . . . . . . . . . . . 10 73 5.3. User Privacy . . . . . . . . . . . . . . . . . . . . . . . 10 74 5.4. Topology Hiding . . . . . . . . . . . . . . . . . . . . . 10 75 5.5. Coexistence with Caching . . . . . . . . . . . . . . . . . 10 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 77 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 78 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 79 9. Informative References . . . . . . . . . . . . . . . . . . . . 12 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 82 1. Introduction 84 Peer-to-peer (P2P) applications, such as file sharing, real-time 85 communication, and live media streaming, use a significant amount of 86 Internet resources [WWW.cachelogic.picture] [WWW.wired.fuel]. 87 Different from the client/server architecture, P2P applications 88 access resources such as files or media relays distributed across the 89 Internet and exchange large amounts of data in connections that they 90 establish directly with nodes sharing such resources. 92 One advantage of P2P systems results from the fact that the resources 93 such systems offer are often available through multiple replicas. 94 However, applications generally do not have reliable information of 95 the underlying network and thus have to select among available 96 instances based on information they deduce from empirical 97 measurements that, in some situations, lead to suboptimal choices. 98 For example, one popular metric is an estimation of round-trip time. 99 This choice occurs before actual data transmission begins and thus 100 before the peer can deduce actual throughput. This is one reason why 101 a peer selection algorithm that simply uses round-trip time often 102 results in a sub-optimal choice of peers. 104 Many of today's P2P systems use an overlay network consisting of 105 direct peer connections. Such connections often do not account for 106 the underlying network topology. In addition to having suboptimal 107 performance, such networks can lead to congestion and cause serious 108 inefficiencies. As shown in [ACM.fear], traffic generated by popular 109 P2P applications often cross network boundaries multiple times, 110 overloading links which are frequently subject to congestion 111 [ACM.bottleneck]. Moreover, such transits, besides resulting in a 112 poor experience for the user, can be quite costly to the network 113 operator. 115 Recent studies [ACM.ispp2p] [WWW.p4p.overview] [ACM.ono] show a 116 possible solution to this problem. Internet Service Providers (ISP), 117 network operators or third parties can collect reliable network 118 information. This information includes relevant information such as 119 topology or instantaneous bandwidth available. Normally, such 120 information is rather "static", i.e., information which can change 121 over time but on a much longer time scale than information used for 122 congestion control on the transport layer. By providing this 123 information to P2P applications, it would be possible to greatly 124 increase application performance, reduce congestion and optimize the 125 overall traffic across different networks. Presumably both, the 126 application and the network operator, can benefit from the fact that 127 such information is being provided to (and used by) the application. 128 Thus, network operators have an incentive to provide (either directly 129 themselves or indirectly through a third party) such information and 130 applications have an incentive to use such information. This 131 document gives the problem statement of optimizing traffic generated 132 by P2P applications using information provided by a separate party. 134 Section 3 introduces the problem. Section 4 describes some use cases 135 where both P2P applications and network operators would benefit from 136 a solution to such a problem. Section 5 describes the main issues to 137 consider when designing such a solution. 139 1.1. Research or Engineering? 141 The papers [I-D.bonaventure-informed-path-selection] and [ACM.ispp2p] 142 [WWW.p4p.overview] are examples of contemporary solution proposals 143 that address the problem described in this document. Moreover, these 144 proposals have encouraging simulation and field test results. These 145 and similar, independent, solutions all consist of two essential 146 parts: 147 o a discovery mechanism which a P2P application uses to find a 148 reliable information source; 149 o a protocol P2P applications use to query such sources in order to 150 retrieve the information needed to perform better-than-random 151 selection of the endpoints providing a desired resource. 153 It is not easy to foresee how such solutions would perform in the 154 Internet, but a more accurate evaluation would require representative 155 data collected from real systems by a critical mass of users. 157 However, wide adoption will probably never happen without an 158 agreement on a common solution based on an open standard. 160 2. Definitions 162 The following terms have special meaning in the definition of the 163 Application-Layer Traffic Optimization (ALTO) problem. 165 Application: A distributed communication system (e.g., file sharing) 166 that uses the ALTO service to improve its performance (or quality 167 of experience) while optimizing resource consumption in the 168 underlying network infrastructure. Applications may use the P2P 169 model to organize themselves, use the client-server model, or use 170 a hybrid of both. 171 Peer: A specific participant in an application. Colloquially, a 172 peer refers to a participant in a P2P network or system, and this 173 definition does not violate that assumption. If the basis of the 174 application is the client-server or hybrid model, then the usage 175 of the terms "client" and "server" disambiguates the peer's role. 177 P2P: Peer-to-Peer. 178 Resource: Content, such as a file or a chunk of a file or a server 179 process, for example to relay a media stream or perform a 180 computation, which applications can access. In the ALTO context, 181 a resource is often available in several equivalent replicas. In 182 addition, different peers share these resources, often 183 simultaneously. 184 Resource Identifier: An application layer identifier used to 185 identify a resource, no matter how many replicas exist. 186 Resource Provider: For P2P applications, a resource provider is a 187 specific peer that provides some resources. For client-server or 188 hybrid applications, a provider is a server that hosts a resource. 189 Resource Consumer: For P2P applications, a resource consumer is a 190 specific peer that needs to access resources. For client-server 191 or hybrid applications, a consumer is a client that needs to 192 access resources. 193 Transport Address: All address information that a resource consumer 194 needs to access the desired resource at a specific resource 195 provider. This information usually consists of the resource 196 provider's IP address and possibly other information, such as a 197 transport protocol identifier or port numbers. 198 Overlay Network: A virtual network consisting of direct connections 199 on top of another network, established by a group of peers. 200 Resource Directory: An entity that is logically separate from the 201 resource consumer that assists a resource consumer to identify a 202 set of resource providers. Some P2P applications refer to the 203 resource directory as a P2P tracker. 204 Host Location Attribute: Information about the location of a host in 205 the network topology. The ALTO service gives recommendations 206 based on this information. A host location attribute may consist 207 of, for example, an IP address, an address prefix or address range 208 that contains the host, an autonomous system (AS) number, or any 209 other localization attribute. These different options may provide 210 different levels of detail. Depending on the system architecture, 211 this may have implications on the quality of the recommendations 212 ALTO is able to provide, on whether recommendations can be 213 aggregated, and on how much privacy-sensitive information about 214 users might be disclosed to additional parties. 215 ALTO Service: Several resource providers may be able to provide the 216 same resource. The ALTO service gives guidance to a resource 217 consumer or resource directory about which resource provider(s) to 218 select, in order to optimize the client's performance or quality 219 of experience while optimizing resource consumption in the 220 underlying network infrastructure. 222 ALTO Server: A logical entity that provides interfaces to query the 223 ALTO service. 224 ALTO Client: The logical entity that sends ALTO queries. Depending 225 on the architecture of the application one may embed it in the 226 resource consumer or in the resource directory. 227 ALTO Query: A message sent from an ALTO client to an ALTO server, 228 which requests guidance from the ALTO Service. 229 ALTO Response: A message sent from an ALTO server to an ALTO client, 230 which contains guiding information from the ALTO service. 231 ALTO Transaction: An ALTO transaction consists of an ALTO query and 232 the corresponding ALTO response. 233 Local Traffic: Traffic that stays within the network infrastructure 234 of one Internet Service Provider (ISP). This type of traffic 235 usually results in the least cost for the ISP. 236 Peering Traffic: Internet traffic exchanged by two Internet Service 237 Providers whose networks connect directly. Apart from 238 infrastructure and operational costs, peering traffic is often 239 free to the ISPs, within the contract of a peering agreement. 240 Transit Traffic: Internet traffic exchanged on the basis of economic 241 agreements amongst Internet Service Providers (ISP). An ISP 242 generally pays a transit provider for the delivery of traffic 243 flowing between its network and remote networks that the ISP does 244 not have a direct connection. 245 Application Protocol: A protocol used by the application for 246 establishing an overlay network between the peers and exchanging 247 data on it, as well as for data exchange between peers and 248 resource directories if applicable. These protocols play an 249 important role in the overall ALTO architecture, however, defining 250 them is out of the scope of the ALTO WG."> 251 ALTO Client Protocol: The protocol used for sending ALTO queries and 252 ALTO replies between ALTO client and ALTO Server. 253 Provisioning Protocol: A protocol used for populating the ALTO 254 server with topology-related information. 255 Inter-ALTO Server Protocol: The protocol used for synchronization, 256 query forwarding, or referral between ALTO servers that have been 257 provisioned with only partial knowledge of the topology-related 258 information (e.g., on a per-domain basis). 260 +------+ 261 +-----+ | Peers 262 +-----+ +------+ +=====| |--+ 263 | |.......| |====+ +--*--+ 264 +-----+ +------+ | * 265 Source of ALTO | * 266 topological service | +--*--+ 267 information +=====| | Super-peer 268 +-----+ (Tracker, proxy) 269 Legend: 270 === ALTO client protocol 271 *** Application protocol (out of scope) 272 ... Provisioning or initialization (out of scope) 274 Figure 1 - Overview of protocol interaction between ALTO elements 276 Figure 1 shows the scope of the ALTO client protocol: Peers or super- 277 peers can use such a protocol to query an ALTO-service. The mapping 278 of topological information onto an ALTO service as well as the 279 application protocol interaction between peers and super-peers are 280 out of scope for the ALTO client 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 for 288 packets traveling between specific source and destination addresses 289 and based on requirements such as low latency, high reliability, and 290 priority. Such solutions are usually implemented at the link and 291 network layers, and tend to be almost transparent. At best, 292 applications can only "mark" the traffic they generate with the 293 corresponding properties. 295 However, P2P applications that are today posing serious challenges to 296 Internet infrastructures do not benefit much from the above route- 297 based techniques. Cooperating with external services aware of the 298 network topology could greatly optimize the traffic the P2P 299 application generates. In fact, when a P2P application needs to 300 establish a connection, the logical target is not a host, but rather 301 a resource (e.g., a file or a media relay) that is often available in 302 multiple instances on different peers. Selection of the closest one 303 -- or, in general, the best from an overlay topological proximity -- 304 has much more impact on the overall traffic than the route followed 305 by its packets to reach the endpoint. 307 Optimization of peer selection is particularly important in the 308 initial phase of the process. Consider a P2P protocol such as 309 BitTorrent, where a querying peer receives a list of candidate 310 destinations where a resource resides. From this list, the peer will 311 derive a smaller set of candidates to connect to and exchange 312 information with. In another example, a streaming video client may 313 be provided with a list of destinations from which it can stream 314 content. In both cases, the use of topology information in an early 315 stage will allow applications to improve their performance and will 316 help ISPs make a better use of their network resources. In 317 particular, an economic goal for ISPs is to reduce the transit 318 traffic on interdomain links. 320 Addressing the Application-Layer Traffic Optimization (ALTO) problem 321 means, on the one hand, deploying an ALTO service to provide 322 applications with information regarding the underlying network and, 323 on the other hand, enhancing applications in order to use such 324 information to perform better-than-random selection of the endpoints 325 they establish connections with. 327 4. Use Cases 329 4.1. File sharing 331 File sharing applications allow users to search for content shared by 332 other users and download it. Typically, search results consist of 333 many instances of the same file (or chunk of a file) available from 334 multiple sources. The goal of an ALTO solution is to help peers find 335 the best ones according to the underlying networks. 337 On the application side, integration of ALTO functionalities may 338 happen at different levels. For example, in the completely 339 decentralized Gnutella network, selection of the best sources is 340 totally up to the user. In systems like BitTorrent and eDonkey, 341 central elements such as trackers or servers act as mediators. 342 Therefore, in the former case, optimization would require 343 modification in the applications, while in the latter it could just 344 be implemented in some central elements. 346 4.2. Cache/Mirror Selection 348 Providers of popular content like media and software repositories 349 usually resort to geographically distributed caches and mirrors for 350 load balancing. Selection of the proper mirror/cache for a given 351 user is today based on inaccurate geolocation data, on proprietary 352 network location systems or often delegated to the user himself. An 353 ALTO solution could be easily adopted to ease such a selection in an 354 automated way. 356 4.3. Live Media Streaming 358 P2P applications for live streaming allow users to receive multimedia 359 content produced by one source and targeted to multiple destinations, 360 in a real-time or near-real-time way. This is particularly important 361 for users or networks that do not support multicast. Peers often 362 participate in the distribution of the content, acting as both 363 receivers and senders. The goal of an ALTO solution is to help peers 364 to find the best sources and the best destinations for media flows 365 they receive and relay. 367 4.4. Realtime Communications 369 P2P real-time communications allow users to establish direct media 370 flows for real-time audio, video, and real-time text calls or to have 371 text chats. In the basic case, media flows directly between the two 372 endpoints. However, unfortunately a significant portion of users 373 have limited access to the Internet due to NATs, firewalls or 374 proxies. Thus, other elements need to relay the media. Such media 375 relays are distributed over the Internet with a public addresses. An 376 ALTO solution needs to help peers to find the best relays. 378 4.5. Distributed Hash Tables 380 Distributed hash tables (DHT) are a class of overlay algorithms used 381 to implement lookup functionalities in popular P2P systems, without 382 using centralized elements. In such systems, peers maintain 383 addresses of other peers participating in the same DHT in a routing 384 table, sorted according to specific criteria. An ALTO solution will 385 provide valuable information for DHT algorithms. 387 5. The Problem in Detail 389 This section introduces some aspects to keep in consideration when 390 designing an ALTO service to provide applications with information 391 they can use to perform better-than-random peer selection. 393 5.1. ALTO Service Providers 395 At least three different kinds of entities can provide ALTO services: 396 1. Network operators: usually have full knowledge of the network 397 they administer and are aware of the topology and policies that 398 transit and peering traffic are subject to; 400 2. Third parties: are entities different from the network operators, 401 but which may have collected network information. Examples of 402 such entities are content delivery networks like Akamai, which 403 control wide and highly distributed infrastructures, or companies 404 providing an ALTO service on behalf of ISPs (and thus acquire the 405 information from the ISPs themselves); 406 3. User communities: run distributed algorithms, for example for 407 estimating the topology of the Internet. 409 5.2. Discovery of ALTO servers 411 As a direct consequence of the totally decentralized architecture of 412 the Internet, it seems almost impossible to centralize all 413 information P2P applications may need to optimize traffic they 414 generate. Therefore, any solution for the ALTO problem will need to 415 specify a mechanism for applications to find a proper ALTO server to 416 query. 418 It is important to note that, depending on the implementation of the 419 ALTO service, an ALTO server could be a centralized entity, for 420 example deployed by the network operator, as well as a ephemeral node 421 participating in a distributed algorithm. 423 5.3. User Privacy 425 Information provided by the ALTO client querying the ALTO server 426 could help increase the level of accuracy in the replies. For 427 example, if the querying client indicates what kind of application it 428 is using (e.g. real-time communications or bulk data transfer), the 429 server will be able to indicate priorities in its replies 430 accommodating the requirements of the traffic the application will 431 generate. However, it is important that for using an ALTO service 432 the application does not have to disclose information it may consider 433 sensitive. 435 5.4. Topology Hiding 437 Operators can play an important role in addressing the ALTO problem, 438 but they generally consider network information they own to be 439 confidential. Therefore, in order to succeed and achieve wide 440 adoption, any solution should provide a method to help P2P 441 applications in peer selection without explicitly disclosing topology 442 of the underlying network. 444 5.5. Coexistence with Caching 446 Caching is a common approach to optimizing traffic generated by 447 applications that require large data transfers. In some cases, such 448 techniques have proven to be extremely effective in both enhancing 449 user experience and saving network resources. However, they have two 450 main limits in respect to the solutions based on the provision of 451 topology information: 452 1. Application specificity: since a cache is meant to replace the 453 source of the content being accessed -- either explicitly or 454 transparently -- it must be able to speak the same protocol with 455 the querying peer. For this reason, caching solutions can be 456 reasonably adopted only for the most popular applications, such 457 as HTTP and BitTorrent. 458 2. Content awareness: since caches need to store the content being 459 delivered, they are subject to legal issues whenever the user 460 does not have the right to access or distribute such content. 461 This limitation makes caching approaches that do not (or cannot) 462 support digital rights management unusable for distributing 463 copyrighted material. Since, it is very difficult for an 464 abstract file sharing proxy to know all of the legal parameters 465 around distributing content, this makes caching unusable for many 466 file-sharing systems. Since this is a legal and not technical 467 issue, the solution would be at the legal, not network, layer. 469 In general, solutions based on provision of topology information need 470 not interfere with caching. In fact, if the ALTO service used by 471 applications is aware of the presence of caches, the service can 472 indicate this in its response, marking them with higher priorities to 473 achieve greater optimization. 475 6. Security Considerations 477 The approach proposed in this document asks P2P applications to 478 delegate a portion of their routing capability to third parties. 479 This gives the third party a significant role in P2P systems. 481 In the case where the network operator deploys an ALTO solution, it 482 is conceivable that the P2P community would consider it hostile 483 because the operator could, for example: 484 o redirect applications to corrupted mediators providing malicious 485 content; 486 o track connections to perform content inspection or logging; and 487 o apply policies based on criteria other than network efficiency. 488 For example, the service provider may suggest routes sub-optimal 489 from the user's perspective to avoid peering points regulated by 490 inconvenient economic agreements. 492 It is important to note that ALTO is completely optional for P2P 493 applications and its purpose is to help improve performance of such 494 applications. If, for some reason, it fails to achieve this purpose, 495 it would simply fail to gain popularity and the P2P community would 496 not use it. 498 Even in cases where the ALTO service provider maliciously alters 499 results returned by queries after ALTO has gained popularity (i.e., 500 the service provider plays well for a while to become popular and 501 then starts misbehaving), it would be easy for P2P application 502 maintainers and users to revert to solutions that are not using it. 504 7. IANA Considerations 506 None. 508 8. Acknowledgments 510 The basis of this document is draft-marocco-alto-problem-statement, 511 written by Enrico Marocco and Vijay Gurbani. The authors of this 512 draft continued editing the previous version in agreement with the 513 original authors. 515 Vinay Aggarwal and the P4P working group conducted the research work 516 done outside the IETF. Emil Ivov, Rohan Mahy, Anthony Bryan, 517 Stanislav Shalunov, Laird Popkin, Stefano Previdi, Reinaldo Penno, 518 Dimitri Papadimitriou, Sebastian Kiesel, and many others provided 519 insightful discussions, specific comments and much needed 520 corrections. 522 Thanks in particular to Richard Yang for several reviews. 524 9. Informative References 526 [ACM.bottleneck] 527 Akella, A., Seshan, S., and A. Shaikh, "An Empirical 528 Evaluation of WideArea Internet Bottlenecks", Proceedings 529 of ACM SIGCOMM, October 2003. 531 [ACM.fear] 532 Karagiannis, T., Rodriguez, P., and K. Papagiannaki, 533 "Should ISPs fear Peer-Assisted Content Distribution?", 534 In ACM USENIX IMC, Berkeley 2005. 536 [ACM.ispp2p] 537 Aggarwal, V., Feldmann, A., and C. Scheideler, "Can ISPs 538 and P2P systems co-operate for improved performance?", In 539 ACM SIGCOMM Computer Communications Review 540 (CCR), 37:3, pp. 29-40. 542 [ACM.ono] Choffnes, D. and F. Bustamante, "Taming the Torrent: A 543 practical approach to reducing cross-ISP traffic in P2P 544 systems", Proceedings of ACM SIGCOMM, August 2008. 546 [I-D.bonaventure-informed-path-selection] 547 Saucez, D. and B. Donnet, "The case for an informed path 548 selection service", 549 draft-bonaventure-informed-path-selection-00 (work in 550 progress), February 2008. 552 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 553 Label Switching Architecture", RFC 3031, January 2001. 555 [RFC3260] Grossman, D., "New Terminology and Clarifications for 556 Diffserv", RFC 3260, April 2002. 558 [SIGCOMM.resprox] 559 Gummadi, K., Gummadi, R., Ratnasamy, S., Gribble, S., 560 Shenker, S., and I. Stoica, "The impact of DHT routing 561 geometry on resilience and proximity", Proceedings of ACM 562 SIGCOMM, August 2003. 564 [WWW.cachelogic.picture] 565 Parker, A., "The true picture of peer-to-peer 566 filesharing", . 568 [WWW.p4p.overview] 569 Xie, H., Krishnamurthy, A., Silberschatz, A., and R. Yang, 570 "P4P: Explicit Communications for Cooperative Control 571 Between P2P and Network Providers", 572 . 574 [WWW.wired.fuel] 575 Glasner, J., "P2P fuels global bandwidth binge", 576 . 578 Authors' Addresses 580 Jan Seedorf 581 NEC Laboratories Europe, NEC Europe Ltd. 582 Kurfuersten-Anlage 36 583 Heidelberg 69115 584 Germany 586 Phone: +49 (0) 6221 4342 221 587 Email: jan.seedorf@nw.neclab.eu 588 URI: http://www.nw.neclab.eu 590 Eric W. Burger 591 This Space for Sale 592 New Hampshire 593 USA 595 Phone: 596 Fax: +1 530 267 7447 597 Email: eburger@standardstrack.com 598 URI: http://www.standardstrack.com