idnits 2.17.1 draft-ietf-decade-problem-statement-06.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 date (May 7, 2012) is 4372 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'Octoshape' is defined on line 483, but no explicit reference was found in the text == Unused Reference: 'PPLive' is defined on line 486, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-p2psip-base-21 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DECADE H. Song 3 Internet-Draft N. Zong 4 Intended status: Informational Huawei 5 Expires: November 8, 2012 Y. Yang 6 Yale University 7 R. Alimi 8 Google 9 May 7, 2012 11 DECoupled Application Data Enroute (DECADE) Problem Statement 12 draft-ietf-decade-problem-statement-06 14 Abstract 16 Peer-to-peer (P2P) applications have become widely used on the 17 Internet today and make up a large portion of the traffic in many 18 networks. In P2P applications, one technique for reducing the 19 transit and uplink P2P traffic is to introduce storage capabilities 20 within the network. Traditional caches (e.g., P2P and Web caches) 21 provide such storage, but they are complex (due to explicitly 22 supporting individual P2P application protocols and cache refresh 23 mechanisms) and they do not allow users to manage access to content 24 in the cache. For example, content providers wishing to use in- 25 network storage cannot easily control cache access and resource usage 26 policies to satisfy their own requirements. This document discusses 27 the introduction of in-network storage for P2P applications, and 28 shows the need for a standard protocol for accessing this storage. 30 Status of this Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on November 8, 2012. 47 Copyright Notice 48 Copyright (c) 2012 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Terminology and Concepts . . . . . . . . . . . . . . . . . . . 4 65 3. The Problems . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3.1. P2P infrastructural stress and inefficiency . . . . . . . 4 67 3.2. P2P cache: a complex in-network storage . . . . . . . . . 5 68 3.3. Ineffective integration of P2P applications . . . . . . . 6 69 4. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 6 70 4.1. BitTorrent . . . . . . . . . . . . . . . . . . . . . . . . 6 71 4.2. Content Publisher . . . . . . . . . . . . . . . . . . . . 7 72 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 73 5.1. Denial of Service Attacks . . . . . . . . . . . . . . . . 8 74 5.2. Copyright and Legal Issues . . . . . . . . . . . . . . . . 8 75 5.3. Traffic Analysis . . . . . . . . . . . . . . . . . . . . . 8 76 5.4. Modification of Information . . . . . . . . . . . . . . . 8 77 5.5. Masquerade . . . . . . . . . . . . . . . . . . . . . . . . 9 78 5.6. Disclosure . . . . . . . . . . . . . . . . . . . . . . . . 9 79 5.7. Message Stream Modification . . . . . . . . . . . . . . . 9 80 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 81 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 82 8. Informative References . . . . . . . . . . . . . . . . . . . . 10 83 Appendix A. Other Related Work in IETF . . . . . . . . . . . . . 11 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 86 1. Introduction 88 Peer-to-peer (P2P) applications, including both P2P streaming and P2P 89 filesharing applications, make up a large fraction of the traffic in 90 many ISP networks today. One way to reduce bandwidth usage by P2P 91 applications is to introduce storage capabilities in networks. 92 Allowing P2P applications to store and retrieve data from inside 93 networks can reduce traffic on the last-mile uplink, as well as on 94 backbone and transit links. 96 P2P caches provide in-network storage and have been deployed in some 97 networks. However, the current P2P caching architecture poses 98 challenges to both P2P cache vendors and P2P application developers. 99 For P2P cache vendors, it is challenging to support a number of 100 continuously evolving P2P application protocols, due to lack of 101 documentation, ongoing protocol changes, and rapid introduction of 102 new features by P2P applications. For P2P applications, closed P2P 103 caching systems limit P2P applications from effectively utilizing in- 104 network storage. In particular, P2P caches typically do not allow 105 users to explicitly store content into in-network storage. They also 106 do not allow users to implement control over the content that has 107 been placed into the in-network storage. 109 P2P applications suffer decreased efficiency, and the network 110 infrastructure suffers increased load because there is no 111 standardized interface for accessing storage and data transport 112 services in the Internet. 114 Both of these challenges can be effectively addressed by using an 115 open, standard protocol to access in-network storage [Data_Lockers]. 116 P2P applications can store and retrieve content in the in-network 117 storage, as well as control resources (e.g., bandwidth, connections) 118 consumed by peers in a P2P application. As a simple example, a peer 119 of a P2P application may upload to other peers through its in-network 120 storage, saving its usage of last-mile uplink bandwidth. 122 In this document, we distinguish between two functional components of 123 the native P2P application protocol: signaling and data access. 124 Signaling includes operations such as handshaking and discovering 125 peer and content availability. The data access component transfers 126 content from one peer to another. 128 In essence, coupling of the signaling and data access makes in- 129 network storage very complex to support various application services. 130 However, these applications have common requirements for data access, 131 making it possible to develop a standard protocol. 133 2. Terminology and Concepts 135 The following terms have special meaning in the definition of the in- 136 network storage system. 138 in-network storage: A service inside a network that provides 139 storage and bandwidth to network applications. In-network storage 140 may reduce upload/transit/backbone traffic and improve network 141 application performance. The position of in-network storage is in 142 the core of a network, for example, co-located with the border 143 router (network attached storage) or inside a data center. 145 P2P cache (Peer to Peer cache): A kind of in-network storage that 146 understands the signaling and transport of specific P2P 147 application protocols. It caches the content for those specific 148 P2P applications in order to serve peers and reduce traffic on 149 certain links. 151 3. The Problems 153 The emergence of peer-to-peer (P2P) as a major network application 154 (especially P2P file sharing and streaming) has led to substantial 155 opportunities. The P2P paradigm can be utilized to design highly 156 scalable and robust applications at low cost, compared to the 157 traditional client-server paradigm. 159 However, P2P applications also face substantial design challenges. A 160 particular problem facing P2P applications is the additional stress 161 that they place on the network infrastructure. Furthermore, lack of 162 infrastructure support can lead to unstable P2P application 163 performance during peer churns and flash crowds, when a large group 164 of users begin to retrieve the content during a short period of time. 165 A potential way to solve it would be to make it possible for peers 166 that were on bandwidth constrained access to put things in a place 167 that is both not bandwidth constrained and accessible by other peers. 168 These problems are now discussed in further detail. 170 3.1. P2P infrastructural stress and inefficiency 172 A particular problem of the P2P paradigm is the stress that P2P 173 application traffic places on the infrastructure of Internet service 174 providers (ISPs). Multiple measurements (e.g., 175 [Internet_Study_2008-2009]) have shown that P2P traffic has become a 176 major type of traffic on some networks. Furthermore, the 177 inefficiency of network-agnostic peering (at the P2P transmission 178 level) leads to unnecessary traversal across network domains or 179 spanning the backbone of a network [RFC5693]. 181 Using network information alone to construct more efficient P2P 182 swarms is not sufficient to reduce P2P traffic in access networks, as 183 the total access upload traffic is equal to the total access download 184 traffic in a traditional P2P system. On the other hand, it is 185 reported that P2P traffic is becoming the dominant traffic on the 186 access networks of some networks, reaching as high as 50-60% on the 187 downlinks and 60-90% on the uplinks ([DCIA], [ICNP], 188 [ipoque.P2P_survey.], [P2P_file_sharing]). Consequently, it becomes 189 increasingly important to reduce upload access traffic, in addition 190 to cross-domain and backbone traffic. 192 The inefficiency is also represented when traffic is sent upstream as 193 many times as there are remote peers interested in getting the 194 corresponding information. For example, the P2P application transfer 195 completion times remain affected by potentially (relatively) slow 196 upstream transmission. Similarly, the performance of real-time P2P 197 applications may be affected by potentially (relatively) higher 198 upstream latencies. 200 3.2. P2P cache: a complex in-network storage 202 An effective technique to reduce P2P infrastructural stress and 203 inefficiency is to introduce in-network storage. The existing in- 204 network storage systems can be found in [RFC6392]. 206 In the current Internet, in-network storage is introduced as P2P 207 caches, either transparently or explicitly as a P2P peer. To provide 208 service to a specific P2P application, the P2P cache server must 209 support the specific signaling and transport protocols of the 210 specific P2P application. This can lead to substantial complexity 211 for the P2P Cache vendor. 213 First, there are many P2P applications on the Internet (e.g., 214 BitTorrent, eMule, Flashget, and Thunder for file sharing; Abacast, 215 Kontiki, Octoshape, PPLive, PPStream, and UUSee for P2P streaming). 216 Consequently, a P2P cache vendor faces the challenge of supporting a 217 large number of P2P application protocols, leading to product 218 complexity and increased development cost. 220 Furthermore, a specific P2P application protocol may evolve 221 continuously, to add new features or fix bugs. This forces a P2P 222 cache vendor to continuously update to track the changes of the P2P 223 application, leading to product complexity and increased costs. 225 Third, many P2P applications use proprietary protocols or support 226 end-to-end encryption. This can render P2P caches ineffective. So 227 these three problems make the P2P cache as a network middle-box, hard 228 to support these P2P application distribution in their own ways. 230 Finally, a P2P cache is likely to be much better connected to end 231 hosts than remote peers that connected to end hosts. Without the 232 ability to manage bandwidth usage, the P2P cache may increase the 233 volume of download traffic, which runs counter to the reduction of 234 upload access traffic. 236 3.3. Ineffective integration of P2P applications 238 As P2P applications evolve, it has become increasingly clear that 239 usage of in-network resources can improve user experience. For 240 example, multiple P2P streaming systems seek additional in-network 241 resources during a flash crowd, such as just before a major live 242 streaming event. In asymmetric networks when the aggregated upload 243 bandwidth of a channel cannot meet the download demand, a P2P 244 application may seek additional in-network resources to maintain a 245 stable system. 247 However, some P2P applications using in-network infrastructural 248 resources require flexibility in implementing resource allocation 249 policies. A major competitive advantage of many successful P2P 250 systems is their substantial expertise in how to most efficiently 251 utilize peer and infrastructural resources. For example, many live 252 P2P systems have specific algorithms to select those peers that 253 behave as stable, higher-bandwidth sources. Similarly, the higher- 254 bandwidth sources frequently use algorithms to chose to which peers 255 the source should send content. Developers of these systems continue 256 to fine-tune these algorithms over time. 258 To permit developers to evolve and fine-tune their algorithms and 259 policies, the in-network storage should expose basic mechanisms and 260 allow as much flexibility as possible to P2P applications. This 261 conforms to the end-to-end systems principle and allows innovation 262 and satisfaction of specific business goals. Existing techniques for 263 P2P application in-network storage lack these capabilities. 265 4. Usage Scenarios 267 Usage scenarios are presented to illustrate the problems in both 268 Content Distribution Network (CDN) and P2P scenarios. 270 4.1. BitTorrent 272 When a BitTorrent client A uploads a block to multiple peers, the 273 block traverses the last-mile uplink once for each peer. And after 274 that, the peer B who just received the block from A also needs to 275 upload through its own last-mile uplink to others when sharing this 276 block. This is not an efficient use of the last-mile uplink. With 277 in-network storage server however, the BitTorrent client may upload 278 the block to its in-network storage. Peers may retrieve the block 279 from the in-network storage, reducing the amount of data on the last- 280 mile uplink. If supported by the in-network storage, a peer can also 281 save the block in its own in-network storage while it is being 282 retrieved; the block can then be uploaded from the in-network storage 283 to other peers. 285 As previously discussed, BitTorrent or other P2P applications 286 currently cannot explicitly manage which content is placed in the 287 existing P2P caches, nor access and resource control polices. 288 Applications need to retain flexibility to control the content 289 distribution policies and topology among peers. 291 4.2. Content Publisher 293 Content publishers may also utilize in-network storage. For example, 294 consider a P2P live streaming application. A Content Publisher 295 typically maintains a small number of sources, each of which 296 distributes blocks in the current play buffer to a set of the P2P 297 peers. 299 Some content publishers use another hybrid content distribution 300 approach incorporating both P2P and CDN modes. As an example, 301 Internet TV may be implemented as a hybrid CDN/P2P application by 302 distributing content from central servers via a CDN, and also 303 incorporating a P2P mode amongst endhosts and set-top boxes. In- 304 network storage may be beneficial to hybrid CDN/P2P applications as 305 well to support P2P distribution and to enable content publisher 306 standard interfaces and controls. 308 However, there is no standard interface for different content 309 publishers to access in-network storage. One streaming content 310 publisher may need the existing in-network storage to support 311 streaming signaling or such capability, such as transcoding 312 capability, bitmap information, intelligent retransmission, etc, 313 while a different content publisher may only need the in-network 314 storage to distribute files. However it is reasonable that the 315 application services are only supported by content publisher's 316 original servers and clients, and intelligent data plane transport 317 for those content publishers are supported by in-network storage. 319 A content publisher also benefits from a standard interface to access 320 in-network storage servers provided by different providers. The 321 standard interface must allow the content publisher to retain control 322 over content placed in their own in-network storage, and grant access 323 and resources only to the desired endhosts and peers. 325 In the hybrid CDN/P2P scenario, if only the endhosts can store 326 content in the in-network storage server, the content must be 327 downloaded and then uploaded over the last-mile access link before 328 another peer may retrieve it from a in-network storage server. Thus, 329 in this deployment scenario, it may be advantageous for a content 330 publisher or CDN provider to store content in in-network storage 331 servers. 333 5. Security Considerations 335 There are several security considerations to the in-network storage. 337 5.1. Denial of Service Attacks 339 An attacker can try to consume a large portion of the in-network 340 storage, or exhaust the connections of the in-network storage through 341 a Denial of Service (DoS) attack. Authentication, authorization and 342 accounting mechanisms should be considered in the cross domain 343 environment. Limitation of access from an administrative domain sets 344 up barriers for content distribution. 346 5.2. Copyright and Legal Issues 348 Copyright and other laws may prevent the distribution of certain 349 content in various localities. In-network storage operators may 350 adopt system-wide ingress or egress filters to implement necessary 351 policies for storing or retrieving content, and applications may 352 apply DRM to the data stored in the network storage. However, the 353 specification and implementation of such policies (e.g., filtering 354 and DRM) is not in scope for the problem this document proposes 355 solving. 357 5.3. Traffic Analysis 359 If the content is stored in the provider-based in-network storage, 360 there may be a privacy risk that the provider can correlate the 361 people who are accessing the same data object using the same object 362 identity. This correlation can be used to presume that they have the 363 same interest, so as to use it as a basis for a phishing attack. 365 5.4. Modification of Information 367 The modification threat is the danger that some unauthorized entity 368 may alter in-transit in-network storage access messages generated on 369 behalf of an authorized principal in such a way as to effect 370 unauthorized management operations, including falsifying the value of 371 an object. This threat may result in false data being supplied 372 either through the data on a legitimate store being modified, or 373 through a bogus store being introduced into the network. 375 5.5. Masquerade 377 A type of threat action whereby an unauthorized entity gains access 378 to a system or performs a malicious act by illegitimately posing as 379 an authorized entity. In the context of this spec, when accessing 380 in-network storage, one malicious end host can try to act as another 381 authorized end host or application server to access a protected 382 resource in the in-network storage. 384 5.6. Disclosure 386 The disclosure threat is the danger of eavesdropping on the exchanges 387 between in-network storage and application clients. Protecting 388 against this threat may be required as a matter of application 389 policy. 391 5.7. Message Stream Modification 393 The message stream modification threat is the danger that messages 394 may be maliciously re-ordered, delayed or replayed to an extent which 395 is greater than can occur through natural network system, in order to 396 effect unauthorized management operations to in-network storage. If 397 the middle box, such like NAT (network address translator) or proxy 398 between an end host and in-network storage is compromised, it is easy 399 to do the stream modification attack. 401 6. IANA Considerations 403 There are no IANA considerations in this document. 405 7. Acknowledgments 407 We would like to thank the following people for contributing to this 408 document: 410 David Bryan 412 Ronald Bonica 414 Kar Ann Chew 416 Roni Even 417 Lars Eggert 419 Francois Le Faucheur 421 Adrian Farrel 423 Yingjie Gu 425 David Harrington 427 Leif Johansson 429 Hongqiang Liu 431 Tao Ma 433 Borje Ohlman 435 Akbar Rahman 437 Robert Sparks 439 Peter Saint-Andre 441 Sean Turner 443 Yu-shun Wang 445 Richard Woundy 447 Yunfei Zhang 449 8. Informative References 451 [Internet_Study_2008-2009] 452 "Internet Study 2008/2009", . 455 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 456 Optimization (ALTO) Problem Statement", RFC 5693, 457 October 2009. 459 [RFC6392] Alimi, R., Rahman, A., and Y. Yang, "A Survey of In- 460 Network Storage Systems", RFC 6392, October 2011. 462 [Data_Lockers] 463 Yang, Y., "Open Content Distribution using Data Lockers", 464 . 467 [I-D.ietf-p2psip-base] 468 Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and 469 H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) 470 Base Protocol", draft-ietf-p2psip-base-21 (work in 471 progress), March 2012. 473 [DCIA] http://www.dcia.info, "Distributed Computing Industry 474 Association". 476 [ipoque.P2P_survey.] 477 "Emerging Technologies Conference at MIT", Sept. 2007. 479 [P2P_file_sharing] 480 Parker, A., "The true picture of peer-to-peer 481 filesharing", July 2004. 483 [Octoshape] 484 "http://www.octoshape.com/?page=company/about". 486 [PPLive] "http://www.synacast.com/products/". 488 [ICNP] Wu, H., "Challenges and opportunities of Internet 489 developments in China, ICNP 2007 Keynote", Oct. 2007. 491 Appendix A. Other Related Work in IETF 493 (To the RFC editor: Please remove this section and the related 494 references in this section upon publication. The purpose of this 495 section is to give the IESG and RFC editor a better understanding of 496 the current P2P related work in IETF and the relationship with DECADE 497 WG.) 499 Note that DECADE WG's work is independent of current IETF work on 500 P2P. The ALTO work is aimed for better peer selection and the RELOAD 501 [I-D.ietf-p2psip-base] protocol is used for P2P overlay maintenance 502 and resource discovery. 504 The Peer to Peer Streaming Protocol effort in the IETF is 505 investigating the specification of signaling protocols (called the 506 PPSP tracker protocol and peer protocol) for multiple entities (e.g., 507 intelligent endpoints, caches, content distribution network nodes, 508 and/or other edge devices) to participate in P2P streaming systems in 509 both fixed and mobile Internet. As discussed in the PPSP problem 510 statement, one important PPSP use case is the support of an in- 511 network edge cache for P2P Streaming. However, this approach to 512 providing in-network cache has different applicability, different 513 objectives and different implications for the in-network cache 514 operator. The goal of DECADE WG is to provide in-network storage 515 service that can be used for any application transparently to the in- 516 network storage operator: it can be used for any P2P Streaming 517 application (whether it supports PPSP protocols or not), for any 518 other P2P application, and for non P2P applications that simply want 519 to benefit from in-network storage. With DECADE, the operator is 520 providing a generic in-network storage service that can be used by 521 any application without application involvement or awareness by the 522 operator; in the PPSP cache use case, the cache operator is 523 participating in the specific P2P streaming service. 525 DECADE and PPSP can both contribute independently, and (where 526 appropriate) simultaneously, to making content available closer to 527 peers. Here are a number of example scenarios: 529 A given network supports DECADE in-network storage, and its CDN 530 nodes do not participate as PPSP Peers for a given "stream" (e.g., 531 because no CDN arrangement has been put in place between the 532 content provider and the particular network provider). In that 533 case, PPSP Peers will all be "off-net" but will be able to use 534 DECADE in-network storage to exchange chunks. 536 A given network does not support DECADE in-network storage, and 537 (some of) its CDN nodes participate as PPSP Peers for a given 538 "stream" (e.g., say because an arrangement has been put in place 539 between the content provider and the particular network provider). 540 In that case, the CDN nodes will participate as in-network PPSP 541 Peers. The off-net PPSP Peers (i.e., end users) will be able to 542 get chunks from the in-network CDN nodes (using PPSP protocols 543 with the CDN nodes). 545 A given network supports DECADE in-network storage, and (some of) 546 its CDN nodes participate as PPSP Peers for a given "stream" 547 (e.g., because an arrangement has been put in place between the 548 content provider and the particular network provider). In that 549 case, the CDN nodes will participate as in-network PPSP Peers. 550 The off-net PPSP Peers (i.e., end users) will be able to get 551 chunks from the in-network CDN nodes (using PPSP protocols with 552 the CDN nodes) as well as be able to get chunks / share chunks 553 using DECADE in-network storage populated by PPSP Peers (both off- 554 net end-users and in-network CDN Nodes). 556 PPSP and DECADE jointly provide P2P streaming service for 557 heterogeneous networks including both fixed and mobile connections 558 and enables the mobile nodes to use DECADE. In this case there 559 may be some solutions that require more information in PPSP 560 tracker protocol, e.g., the mobile node can indicate its DECADE 561 in-network proxy to the PPSP tracker and the following requesting 562 peer can finish data transfer with the DECADE proxy. 564 An ALTO (Application Layer Traffic Optimization) server provides P2P 565 applications with network information so that they can perform 566 better-than-random initial peer selection [RFC5693]. However, there 567 are limitations on what ALTO can achieve alone. For example, network 568 information alone cannot reduce P2P traffic in access networks, as 569 the total access upload traffic is equal to the total access download 570 traffic in a traditional P2P system. Consequently, it becomes 571 increasingly important to complement the ALTO effort and reduce 572 upload access traffic, in addition to cross-domain and backbone 573 traffic. 575 The IETF Low Extra Delay Background Transport (LEDBAT) Working Group 576 is focusing on techniques that allow large amounts of data to be 577 consistently transmitted without substantially affecting the delays 578 experienced by other users and applications. It is expected that 579 some P2P applications would start using such techniques, thereby 580 somewhat alleviating the perceivable impact (at least on other 581 applications) of their high volume traffic. However, such techniques 582 may not be adopted by all P2P applications. Also, when adopted, 583 these techniques do not remove all inefficiencies, such as those 584 associated with traffic being sent upstream as many times as there 585 are remote peers interested in getting the corresponding information. 586 For example, the P2P application transfer completion times remain 587 affected by potentially (relatively) slow upstream transmission. 588 Similarly, the performance of real-time P2P applications may be 589 affected by potentially (relatively) higher upstream latencies. 591 Authors' Addresses 593 Haibin Song 594 Huawei 595 101 Software Avenue, Yuhua District, 596 Nanjing, Jiangsu Province 210012 597 China 599 Phone: +86-25-56624792 600 Email: haibin.song@huawei.com 601 Ning Zong 602 Huawei 603 101 Software Avenue, Yuhua District, 604 Nanjing, Jiangsu Province 210012 605 China 607 Phone: +86-25-56624760 608 Email: zongning@huawei.com 610 Y. Richard Yang 611 Yale University 613 Email: yry@cs.yale.edu 615 Richard Alimi 616 Google 618 Email: ralimi@google.com