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