idnits 2.17.1 draft-ietf-decade-problem-statement-05.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 (February 8, 2012) is 4460 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-26) exists of draft-ietf-p2psip-base-20 Summary: 0 errors (**), 0 flaws (~~), 2 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: August 11, 2012 Y. Yang 6 Yale University 7 R. Alimi 8 Google 9 February 8, 2012 11 DECoupled Application Data Enroute (DECADE) Problem Statement 12 draft-ietf-decade-problem-statement-05 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 August 11, 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 . . . . . . . . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . 10 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 86 1. Introduction 88 P2P applications, including both P2P streaming and P2P filesharing 89 applications, make up a large fraction of the traffic in many ISP 90 networks today. One way to reduce bandwidth usage by P2P 91 applications is to introduce storage capabilities in the 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. P2P 116 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. 143 P2P cache (Peer to Peer cache): A kind of in-network storage that 144 understands the signaling and transport of specific P2P 145 application protocols. It caches the content for those specific 146 P2P applications in order to serve peers and reduce traffic on 147 certain links. 149 3. The Problems 151 The emergence of peer-to-peer (P2P) as a major network application 152 (especially P2P file sharing and streaming) has led to substantial 153 opportunities. The P2P paradigm can be utilized to design highly 154 scalable and robust applications at low cost, compared to the 155 traditional client-server paradigm. For example, CNN reported that 156 P2P streaming by Octoshape played a major role in its distribution of 157 the historic inauguration address of President Obama[Octoshape]. 158 PPLive, one of the largest P2P streaming vendors, is able to 159 distribute large-scale, live streaming programs to more than 2 160 million users with only a handful of servers [PPLive]. 162 However, P2P applications also face substantial design challenges. A 163 particular problem facing P2P applications is the additional stress 164 that they place on the network infrastructure. Furthermore, lack of 165 infrastructure support can lead to unstable P2P application 166 performance during peer churns and flash crowds, when a large group 167 of users begin to retrieve the content during a short period of time. 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., [Internet Study 2008/ 175 2009][Internet_Study_2008-2009]) have shown that P2P traffic has 176 become a 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. 205 In the current Internet, in-network storage is introduced as P2P 206 caches, either transparently or explicitly as a P2P peer. To provide 207 service to a specific P2P application, the P2P cache server must 208 support the specific signaling and transport protocols of the 209 specific P2P application. This can lead to substantial complexity 210 for the P2P Cache vendor. 212 First, there are many P2P applications on the Internet (e.g., 213 BitTorrent, eMule, Flashget, and Thunder for file sharing; Abacast, 214 Kontiki, Octoshape, PPLive, PPStream, and UUSee for P2P streaming). 215 Consequently, a P2P cache vendor faces the challenge of supporting a 216 large number of P2P application protocols, leading to product 217 complexity and increased development cost. 219 Furthermore, a specific P2P application protocol may evolve 220 continuously, to add new features or fix bugs. This forces a P2P 221 cache vendor to continuously update to track the changes of the P2P 222 application, leading to product complexity and increased costs. 224 Third, many P2P applications use proprietary protocols or support 225 end-to-end encryption. This can render P2P caches ineffective. 227 Finally, a P2P cache is likely to be much better connected to end 228 hosts than to remote peers. Without the ability to manage bandwidth 229 usage, the P2P cache may increase the volume of download traffic, 230 which runs counter to the reduction of upload access traffic. 232 3.3. Ineffective integration of P2P applications 234 As P2P applications evolve, it has become increasingly clear that 235 usage of in-network resources can improve user experience. For 236 example, multiple P2P streaming systems seek additional in-network 237 resources during a flash crowd, such as just before a major live 238 streaming event. In asymmetric networks when the aggregated upload 239 bandwidth of a channel cannot meet the download demand, a P2P 240 application may seek additional in-network resources to maintain a 241 stable system. 243 However, some P2P applications using in-network infrastructural 244 resources require flexibility in implementing resource allocation 245 policies. A major competitive advantage of many successful P2P 246 systems is their substantial expertise in how to most efficiently 247 utilize peer and infrastructural resources. For example, many live 248 P2P systems have specific algorithms to select those peers that 249 behave as stable, higher-bandwidth sources. Similarly, the higher- 250 bandwidth sources frequently use algorithms to chose to which peers 251 the source should send content. Developers of these systems continue 252 to fine-tune these algorithms over time. 254 To permit developers to evolve and fine-tune their algorithms and 255 policies, the in-network storage should expose basic mechanisms and 256 allow as much flexibility as possible to P2P applications. This 257 conforms to the end-to-end systems principle and allows innovation 258 and satisfaction of specific business goals. Existing techniques for 259 P2P application in-network storage lack these capabilities. 261 4. Usage Scenarios 263 Usage scenarios are presented to illustrate the problems in both CDN 264 and P2P scenarios. 266 4.1. BitTorrent 268 When a BitTorrent client A uploads a block to multiple peers, the 269 block traverses the last-mile uplink once for each peer. And after 270 that, the peer B who just received the block from A also needs to 271 upload through its own last-mile uplink to others when sharing this 272 block. This is not an efficient use of the last-mile uplink. With 273 in-network storage server however, the BitTorrent client may upload 274 the block to its in-network storage. Peers may retrieve the block 275 from the in-network storage, reducing the amount of data on the last- 276 mile uplink. If supported by the in-network storage, a peer can also 277 save the block in its own in-network storage while it is being 278 retrieved; the block can then be uploaded from the in-network storage 279 to other peers. 281 As previously discussed, BitTorrent or other P2P applications 282 currently cannot explicitly manage which content is placed in the 283 existing P2P caches, nor can they manage access and resource control 284 polices. Applications need to retain flexibility to control the 285 content distribution policies and topology among peers. 287 4.2. Content Publisher 289 Content publishers may also utilize in-network storage. For example, 290 consider a P2P live streaming application. A Content Publisher 291 typically maintains a small number of sources, each of which 292 distributes blocks in the current play buffer to a set of the P2P 293 peers. 295 Some content publishers use another hybrid content distribution 296 approach incorporating both P2P and CDN modes. As an example, 297 Internet TV may be implemented as a hybrid CDN/P2P application by 298 distributing content from central servers via a CDN, and also 299 incorporating a P2P mode amongst endhosts and set-top boxes. In- 300 network storage may be beneficial to hybrid CDN/P2P applications as 301 well to support P2P distribution and to enable content publisher 302 standard interfaces and controls. 304 However, there is no standard interface for different content 305 publishers to access in-network storage. One streaming content 306 publisher may need the existing in-network storage to support 307 streaming signaling or such capability, such as transcoding 308 capability, bitmap information, intelligent retransmission, etc, 309 while a different content publisher may only need the in-network 310 storage to distribute files. However it is reasonable that the 311 application services are only supported by content publisher's 312 original servers and clients, and intelligent data plane transport 313 for those content publishers are supported by in-network storage. 315 A content publisher also benefits from a standard interface to access 316 in-network storage servers provided by different providers. The 317 standard interface must allow the content publisher to retain control 318 over content placed in their own in-network storage, and grant access 319 and resources only to the desired endhosts and peers. 321 In the hybrid CDN/P2P scenario, if only the endhosts can store 322 content in the in-network storage server, the content must be 323 downloaded and then uploaded over the last-mile access link before 324 another peer may retrieve it from a in-network storage server. Thus, 325 in this deployment scenario, it may be advantageous for a content 326 publisher or CDN provider to store content in in-network storage 327 servers. 329 5. Security Considerations 331 There are several security considerations to the in-network storage. 333 5.1. Denial of Service Attacks 335 An attacker can try to consume a large portion of the in-network 336 storage, or exhaust the connections of the in-network storage through 337 a Denial of Service (DoS) attack. Authentication, authorization and 338 accounting mechanisms should be considered in the cross domain 339 environment. Limitation of access from an administrative domain sets 340 up barriers for content distribution. 342 5.2. Copyright and Legal Issues 344 Copyright and other laws may prevent the distribution of certain 345 content in various localities. In-network storage operators may 346 adopt system-wide ingress or egress filters to implement necessary 347 policies for storing or retrieving content, and applications may 348 apply DRM to the data stored in the network storage. However, the 349 specification and implementation of such policies (e.g., filtering 350 and DRM) is outside of the scope of this document. 352 5.3. Traffic Analysis 354 If the content is stored in the provider-based in-network storage, 355 there may be a privacy risk that the provider can correlate the 356 people who are accessing the same data object using the same object 357 identity. 359 5.4. Modification of Information 361 The modification threat is the danger that some unauthorized entity 362 may alter in-transit in-network storage access messages generated on 363 behalf of an authorized principal in such a way as to effect 364 unauthorized management operations, including falsifying the value of 365 an object. See [RFC3414]. 367 5.5. Masquerade 369 The masquerade threat is the danger that management operations may be 370 attempted by assuming the identity of another user that has the 371 appropriate authorizations. See [RFC3414]. 373 5.6. Disclosure 375 The disclosure threat is the danger of eavesdropping on the exchanges 376 between in-network storage and application clients. Protecting 377 against this threat may be required as a matter of application 378 policy. See [RFC3414]. 380 5.7. Message Stream Modification 382 The message stream modification threat is the danger that messages 383 may be maliciously re-ordered, delayed or replayed to an extent which 384 is greater than can occur through natural network system, in order to 385 effect unauthorized management operations. See [RFC3414]. 387 6. IANA Considerations 389 There are no IANA considerations in this document. 391 7. Acknowledgments 393 We would like to thank the following people for contributing to this 394 document: 396 David Bryan 398 Kar Ann Chew 400 Roni Even 402 Lars Eggert 404 Yingjie Gu 406 Francois Le Faucheur 408 Hongqiang Liu 410 Tao Ma 412 Borje Ohlman 414 Akbar Rahman 416 Yu-shun Wang 417 Richard Woundy 419 Yunfei Zhang 421 8. Informative References 423 [Internet_Study_2008-2009] 424 "Internet Study 2008/2009", . 427 [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model 428 (USM) for version 3 of the Simple Network Management 429 Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. 431 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 432 Optimization (ALTO) Problem Statement", RFC 5693, 433 October 2009. 435 [I-D.ietf-p2psip-base] 436 Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and 437 H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) 438 Base Protocol", draft-ietf-p2psip-base-20 (work in 439 progress), January 2012. 441 [DCIA] http://www.dcia.info, "Distributed Computing Industry 442 Association". 444 [ipoque.P2P_survey.] 445 "Emerging Technologies Conference at MIT", Sept. 2007. 447 [P2P_file_sharing] 448 Parker, A., "The true picture of peer-to-peer 449 filesharing", July 2004. 451 [Octoshape] 452 "http://www.octoshape.com/?page=company/about". 454 [PPLive] "http://www.synacast.com/products/". 456 [ICNP] Wu, H., "Challenges and opportunities of Internet 457 developments in China, ICNP 2007 Keynote", Oct. 2007. 459 Appendix A. Other Related Work in IETF 461 (To the RFC editor: Please remove this section and the related 462 references in this section upon publication. The purpose of this 463 section is to give the IESG and RFC editor a better understanding of 464 the current P2P related work in IETF and the relationship with DECADE 465 WG.) 467 Note that DECADE WG's work is independent of current IETF work on 468 P2P. The ALTO work is aimed for better peer selection and the RELOAD 469 [I-D.ietf-p2psip-base] protocol is used for P2P overlay maintenance 470 and resource discovery. 472 The Peer to Peer Streaming Protocol effort in the IETF is 473 investigating the specification of signaling protocols (called the 474 PPSP tracker protocol and peer protocol) for multiple entities (e.g. 475 intelligent endpoints, caches, content distribution network nodes, 476 and/or other edge devices) to participate in P2P streaming systems in 477 both fixed and mobile Internet. As discussed in the PPSP problem 478 statement, one important PPSP use case is the support of an in- 479 network edge cache for P2P Streaming. However, this approach to 480 providing in-network cache has different applicability, different 481 objectives and different implications for the in-network cache 482 operator. The goal of DECADE WG is to provide in-network storage 483 service that can be used for any application transparently to the in- 484 network storage operator: it can be used for any P2P Streaming 485 application (whether it supports PPSP protocols or not), for any 486 other P2P application, and for non P2P applications that simply want 487 to benefit from in-network storage. With DECADE, the operator is 488 providing a generic in-network storage service that can be used by 489 any application without application involvement or awareness by the 490 operator; in the PPSP cache use case, the cache operator is 491 participating in the specific P2P streaming service. 493 DECADE and PPSP can both contribute independently, and (where 494 appropriate) simultaneously, to making content available closer to 495 peers. Here are a number of example scenarios: 497 A given network supports DECADE in-network storage, and its CDN 498 nodes do not participate as PPSP Peers for a given "stream" (e.g. 499 because no CDN arrangement has been put in place between the 500 content provider and the particular network provider). In that 501 case, PPSP Peers will all be "off-net" but will be able to use 502 DECADE in-network storage to exchange chunks. 504 A given network does not support DECADE in-network storage, and 505 (some of) its CDN nodes participate as PPSP Peers for a given 506 "stream" (e.g. say because an arrangement has been put in place 507 between the content provider and the particular network provider). 508 In that case, the CDN nodes will participate as in-network PPSP 509 Peers. The off-net PPSP Peers (i.e., end users) will be able to 510 get chunks from the in-network CDN nodes (using PPSP protocols 511 with the CDN nodes). 513 A given network supports DECADE in-network storage, and (some of) 514 its CDN nodes participate as PPSP Peers for a given "stream" (e.g. 515 because an arrangement has been put in place between the content 516 provider and the particular network provider). In that case, the 517 CDN nodes will participate as in-network PPSP Peers. The off-net 518 PPSP Peers (i.e., end users) will be able to get chunks from the 519 in-network CDN nodes (using PPSP protocols with the CDN nodes) as 520 well as be able to get chunks / share chunks using DECADE in- 521 network storage populated by PPSP Peers (both off-net end-users 522 and in-network CDN Nodes). 524 PPSP and DECADE jointly provide P2P streaming service for 525 heterogeneous networks including both fixed and mobile connections 526 and enables the mobile nodes to use DECADE. In this case there 527 may be some solutions that require more information in PPSP 528 tracker protocol, e.g., the mobile node can indicate its DECADE 529 in-network proxy to the PPSP tracker and the following requesting 530 peer can finish data transfer with the DECADE proxy. 532 An ALTO (Application Layer Traffic Optimization) server provides P2P 533 applications with network information so that they can perform 534 better-than-random initial peer selection [RFC5693]. However, there 535 are limitations on what ALTO can achieve alone. For example, network 536 information alone cannot reduce P2P traffic in access networks, as 537 the total access upload traffic is equal to the total access download 538 traffic in a traditional P2P system. Consequently, it becomes 539 increasingly important to complement the ALTO effort and reduce 540 upload access traffic, in addition to cross-domain and backbone 541 traffic. 543 The IETF Low Extra Delay Background Transport (LEDBAT) Working Group 544 is focusing on techniques that allow large amounts of data to be 545 consistently transmitted without substantially affecting the delays 546 experienced by other users and applications. It is expected that 547 some P2P applications would start using such techniques, thereby 548 somewhat alleviating the perceivable impact (at least on other 549 applications) of their high volume traffic. However, such techniques 550 may not be adopted by all P2P applications. Also, when adopted, 551 these techniques do not remove all inefficiencies, such as those 552 associated with traffic being sent upstream as many times as there 553 are remote peers interested in getting the corresponding information. 554 For example, the P2P application transfer completion times remain 555 affected by potentially (relatively) slow upstream transmission. 556 Similarly, the performance of real-time P2P applications may be 557 affected by potentially (relatively) higher upstream latencies. 559 Authors' Addresses 561 Haibin Song 562 Huawei 563 101 Software Avenue, Yuhua District, 564 Nanjing, Jiangsu Province 210012 565 China 567 Phone: +86-25-56624792 568 Email: haibin.song@huawei.com 570 Ning Zong 571 Huawei 572 101 Software Avenue, Yuhua District, 573 Nanjing, Jiangsu Province 210012 574 China 576 Phone: +86-25-56624760 577 Email: zongning@huawei.com 579 Y. Richard Yang 580 Yale University 582 Email: yry@cs.yale.edu 584 Richard Alimi 585 Google 587 Email: ralimi@google.com