idnits 2.17.1 draft-ietf-decade-problem-statement-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 14, 2011) is 4791 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-15) exists of draft-ietf-ppsp-problem-statement-01 Summary: 1 error (**), 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: September 15, 2011 Y. Yang 6 Yale University 7 R. Alimi 8 Google 9 March 14, 2011 11 DECoupled Application Data Enroute (DECADE) Problem Statement 12 draft-ietf-decade-problem-statement-03 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 (the download traffic may increase because the in- 21 network storage is likely much better connected). Traditional P2P 22 and Web caches provide such storage, but they are complex (due to 23 explicitly supporting individual P2P application protocols and cache 24 refreshing mechanisms) and they do not allow users to manage access 25 to content in the cache. For example, content providers cannot 26 easily control cache access and resource usage policies to satisfy 27 their own requirements, in the case when the content provider is also 28 the user of in-network storage. This document discusses the 29 introduction of in-network storage for P2P applications, shows the 30 need for a standard protocol for accessing this storage, and 31 identifies the scope of this protocol. The access protocol can also 32 be used by other applications with similar requirements. 34 Status of this Memo 36 This Internet-Draft is submitted to IETF in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF), its areas, and its working groups. Note that 41 other groups may also distribute working documents as Internet- 42 Drafts. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 The list of current Internet-Drafts can be accessed at 49 http://www.ietf.org/ietf/1id-abstracts.txt. 51 The list of Internet-Draft Shadow Directories can be accessed at 52 http://www.ietf.org/shadow.html. 54 This Internet-Draft will expire on September 15, 2011. 56 Copyright Notice 58 Copyright (c) 2011 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (http://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the BSD License. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 2. Terminology and Concepts . . . . . . . . . . . . . . . . . . . 5 75 3. The Problems . . . . . . . . . . . . . . . . . . . . . . . . . 5 76 3.1. P2P infrastructural stress and inefficiency . . . . . . . 6 77 3.2. P2P cache: a complex in-network storage . . . . . . . . . 7 78 3.3. Ineffective integration of P2P applications . . . . . . . 7 79 4. DECADE as an In-network Storage Capability . . . . . . . . . . 8 80 4.1. Data access . . . . . . . . . . . . . . . . . . . . . . . 9 81 4.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 10 82 4.3. Resource control . . . . . . . . . . . . . . . . . . . . . 10 83 5. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 10 84 5.1. BitTorrent . . . . . . . . . . . . . . . . . . . . . . . . 10 85 5.2. Content Publisher . . . . . . . . . . . . . . . . . . . . 12 86 5.3. CDN/P2P hybrid . . . . . . . . . . . . . . . . . . . . . . 12 87 5.4. Data Transfer Scenarios . . . . . . . . . . . . . . . . . 13 88 5.4.1. Both Sender and Receiver Accounts are Used . . . . . . 13 89 5.4.2. Only Sender's Storage Account is Used . . . . . . . . 14 90 5.4.3. Only Receiver's Storage Account is Used . . . . . . . 14 91 5.4.4. No Storage Accounts are Used . . . . . . . . . . . . . 15 92 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 93 6.1. Denial of Service Attacks . . . . . . . . . . . . . . . . 15 94 6.2. Copyright and Legal Issues . . . . . . . . . . . . . . . . 15 95 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 96 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 97 9. Informative References . . . . . . . . . . . . . . . . . . . . 16 98 Appendix A. Other Related Work in IETF . . . . . . . . . . . . . 17 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 101 1. Introduction 103 P2P applications, including both P2P streaming and P2P filesharing 104 applications, make up a large fraction of the traffic in many ISP 105 networks today. One way to reduce bandwidth usage by P2P 106 applications is to introduce storage capabilities in the networks. 107 Allowing P2P applications to store and retrieve data from inside 108 networks can reduce traffic on the last-mile uplink, as well as 109 backbone and transit links [I-D.weaver-alto-edge-caches]. 111 P2P caches provide in-network storage and have been deployed in some 112 networks. But the current P2P caching architecture poses challenges 113 to both P2P cache vendors and P2P application developers. For P2P 114 cache vendors, it is challenging to support a number of continuously 115 evolving P2P application protocols, due to lack of documentation, 116 ongoing protocol changes, and rapid introduction of new features by 117 P2P applications. For P2P applications, closed P2P caching systems 118 limit P2P applications to effectively utilize in-network storage. In 119 particular, P2P caches typically do not allow users to explicitly 120 store content into in-network storage. They do not allow users to 121 implement control over the content that has been placed into the in- 122 network storage either. 124 Both of these challenges can be effectively addressed by using open, 125 standard protocols to access in-network storage. P2P applications 126 can store and retrieve content in the in-network storage, as well as 127 control resources (e.g., network access, connections) consumed by 128 peers in a P2P application. As a simple example, a peer of a P2P 129 application may upload to other peers through its in-network storage, 130 saving its usage of last-mile uplink bandwidth. 132 This document uses DECADE to refer to the protocol(s) developed or 133 employed by the DECADE Working Group to provide these capabilities. 135 In this document, we distinguish between two functional components of 136 the native P2P application protocol: signaling and data access. 137 Signaling includes operations such as handshaking and discovering 138 peer and content availability. The data access component transfers 139 content from one peer to another. 141 With DECADE, P2P applications can still use their native protocols 142 for signaling and data transport. However, they may use a standard 143 protocol for data access incorporating in-network storage, and fall 144 back to their native data transport protocols if in-network storage 145 is not available or not used. 147 In essence, an open, standard protocol to access in-network storage 148 provides an alternative mechanism for P2P application data access 149 that is decoupled from P2P application control and signaling. This 150 decoupling leads to many advantages, which is explained further in 151 Section 4. 153 And further, either the existing P2P cache or any new type of in- 154 network storage should be deployed near the edge of the ISP's network 155 so as to gain better performance. 157 2. Terminology and Concepts 159 The following terms have special meaning in the definition of the in- 160 network storage system. 162 In-network Storage: A service inside a network that provides 163 storage and network access to read/write data to applications. 164 In-network storage may reduce upload/transit/backbone traffic and 165 improve network application performance. 167 IAP (In-network storage Access Protocol): a standard protocol that 168 is spoken between P2P applications and in-network storage. The 169 protocol may also be used between entities implementing the in- 170 network storage service. IAP may be a new protocol or existing 171 protocol with extensions. 173 P2P Cache (Peer to Peer Cache): a kind of in-network storage that 174 understands the signaling and transport of specific P2P 175 application protocols. It caches the content for those specific 176 p2p applications in order to serve peers and reduce traffic on 177 certain links. 179 Content Publisher: An entity that originates content. 181 3. The Problems 183 The emergence of peer-to-peer (P2P) as a major type of network 184 application (esp. P2P file sharing and streaming apps) has led to 185 substantial opportunities. The P2P paradigm can be utilized in 186 designing highly scalable and robust applications at low cost, 187 compared with traditional client-server paradigms. For example, CNN 188 reported that P2P streaming by Octoshape played a major role in its 189 distribution of the historical inauguration address of President 190 Obama[Octoshape]. PPLive, one of the largest P2P streaming vendors, 191 is able to distribute large-scale, live streaming programs to more 192 than 2 million users with only a handful of servers[PPLive]. 194 However, P2P applications also face substantial design challenges. A 195 particular problem facing P2P applications is the substantial stress 196 that they place on the network infrastructure. Also, lack of 197 infrastructure support can lead to unstable P2P application 198 performance during peer churns and flash crowds. During a flash 199 crowd, a large group of application users begin to access the same 200 service during a very short period of time, which is a challenge to 201 the system. Below we elaborate on the problems in more detail. 203 3.1. P2P infrastructural stress and inefficiency 205 A particular problem of the P2P paradigm is the stress that P2P 206 application traffic places on the infrastructure of Internet service 207 providers (ISP). Multiple measurements (e.g., [ipoque.com]) have 208 shown that P2P traffic has become a major type of traffic on some 209 networks. Furthermore, network-agnostic peering (P2P transmission 210 level) leads to unnecessary traversal across network domains or 211 spanning the backbone of a network, leading to network inefficiency 212 [RFC5693]. 214 Recently, the IETF Application Layer Traffic Optimization (ALTO) 215 Working Group was formed to provide P2P applications with network 216 information so that they can perform better-than-random initial peer 217 selection [RFC5693]. However, there are limitations on what ALTO can 218 achieve alone. For example, network information alone cannot reduce 219 P2P traffic in access networks, as the total access upload traffic is 220 equal to the total access download traffic in a pure P2P system. On 221 the other hand, it is reported that P2P traffic is becoming the 222 dominating traffic on the access networks of some networks, reaching 223 as high as 50-60% at the down-links and 60-90% at the uplinks 224 ([DCIA], [ICNP], [ipoque.P2P_survey.], [P2P_file_sharing]). 225 Consequently, it becomes increasingly important to complement the 226 ALTO effort and reduce upload access traffic, in addition to cross- 227 domain and backbone traffic. 229 The IETF Low Extra Delay Background Transport (LEDBAT) Working Group 230 is focusing on techniques that allow large amounts of data to be 231 consistently transmitted without substantially affecting the delays 232 experienced by other users and applications. It is expected that 233 some P2P applications would start using such techniques, thereby 234 somewhat alleviating the perceivable impact (at least on other 235 applications) of their high volume traffic. However, such techniques 236 may not be adopted by all P2P applications. Also, when adopted, 237 these techniques do not remove all inefficiencies, such as those 238 associated with traffic being sent upstream as many times as there 239 are remote peers interested in getting the corresponding information. 240 For example, the P2P application transfer completion times remain 241 affected by potential (relatively) slow upstream transmission. 242 Similarly, the performance of real-time P2P applications may be 243 affected by potential (relatively) higher upstream latencies. 245 3.2. P2P cache: a complex in-network storage 247 An effective technique to reduce P2P infrastructural stress and 248 inefficiency is to introduce in-network storage. For example, in 249 [I-D.weaver-alto-edge-caches], the author demonstrates clearly the 250 potential benefits of introducing in-network storage to improve 251 network efficiency and thus reduce network infrastructure stress. 253 In the current Internet, in-network storage is introduced as P2P 254 caches, either transparently or explicitly as a P2P peer. To provide 255 service to a specific P2P application, the P2P cache server must 256 support the specific signaling and transport protocols of the 257 specific P2P application. This can lead to substantial complexity 258 for the P2P cache vendor. 260 First, there are many P2P applications on the Internet (e.g., 261 BitTorrent, eMule, Flashget, and Thunder for file sharing; Abacast, 262 Kontiki, Octoshape, PPLive, PPStream, and UUSee for P2P streaming). 263 Consequently, a P2P cache vendor faces the challenge of supporting a 264 large number of P2P application protocols, leading to product 265 complexity and increased development cost. 267 Furthermore, a specific P2P application protocol may be evolving 268 continuously, to add new features or fix bugs. This forces a P2P 269 cache vendor to continuously update to track the changes of the P2P 270 application, leading to product complexity, high cost, and low 271 reliability. 273 Third, many P2P applications use proprietary protocols or support 274 end-to-end encryption. This can render P2P caches ineffective. 276 3.3. Ineffective integration of P2P applications 278 As P2P applications evolve, it is becoming increasingly clear that 279 they will need in-network resources to provide positive user 280 experiences. For example, multiple P2P streaming systems seek 281 additional in-network resources during a flash crowd, such as just 282 before a major live streaming event. In asymmetric networks when the 283 aggregated upload bandwidth of a channel cannot meet the download 284 demand, a P2P application may seek additional in-network resources to 285 maintain a stable system. 287 A requirement by some P2P applications in using in-network 288 infrastructural resources, however, is flexibility in implementing 289 resource allocation policies. A major competitive advantage of many 290 successful P2P systems is their substantial expertise in how to most 291 efficiently utilize peer and infrastructural resources. For example, 292 many live P2P systems have specific algorithms to select those peers 293 that behave as stable, higher bandwidth sources. They continue to 294 fine-tune such algorithms. In other words, in-network storage should 295 export basic mechanisms and allow as much flexibility as possible to 296 P2P applications to implement specific policies. This conforms to 297 the end-to-end systems principle and allows innovation and 298 satisfaction of specific business goals. Existing techniques for P2P 299 application in-network storage lack these capabilities. 301 4. DECADE as an In-network Storage Capability 303 The objective of this working group is to design DECADE, which 304 primarily consists of an in-network storage access protocol (IAP) to 305 address the problems discussed in the preceding section. 307 DECADE will provide access to storage and data transport services in 308 the network to P2P applications to improve their efficiency and 309 reduce the stress on the network infrastructure. Unlike the existing 310 P2P caching architecture, DECADE is a standard interface for various 311 P2P applications (both content publishers and end users) to access 312 in-network storage. This decoupling of P2P data access from P2P 313 application control and signaling reduces the complexity of in- 314 network storage services. Furthermore, DECADE provides basic access 315 mechanisms and allows P2P applications to implement flexible policies 316 to create an ecosystem for application innovation and various 317 business goals. Besides that, it also improves the availability of 318 P2P contents because the in-network storage is always-on. 320 IAP 321 -----------+ 322 | | 323 | v 324 +--------------------+ 325 | In-network Storage | 326 +--------------------+ 327 ^ ^ 328 IAP | IAP | 329 +-------------v-+ +-v-------------+ 330 | P2P | | Content | 331 | application | | publishers | 332 | clients | +---------------+ 333 +---------------+ 334 | ^ 335 | | 336 +-------------+ 337 P2P application 338 native protocol 340 Figure 1 Overview of protocol interaction between DECADE elements 342 Specifically, the main component of DECADE is the in-network storage 343 access protocol (IAP), which is a standard, P2P-application-agnostic 344 protocol for different P2P applications to access in-network storage. 345 IAP defines a set of commands that P2P application elements can issue 346 to in-network storage to store and retrieve data. IAP includes the 347 following functionality: 349 (1) Data access provides read/write by users (e.g., P2P application 350 clients and content publishers) to the corresponding in-network 351 storage and between entities implementing the in-network storage; 353 (2) Authorization implements access control to resources provided by 354 in-network storage; 356 (3) Resource control allows users to implement application policies 357 for the corresponding in-network storage. 359 While DECADE will focus on P2P applications, the solution is expected 360 to be applicable in other contexts with similar requirements. 362 4.1. Data access 364 P2P application clients use the IAP protocol to read data from an in- 365 network storage, store data to an in-network storage, or remove data 366 from an in-network storage. The data could be of various types. 367 Existing protocols will be used wherever possible and appropriate to 368 support DECADE's requirements. In particular, data storage, 369 retrieval, and management may be provided by existing IETF protocols. 370 The WG will not limit itself to a single data transport protocol 371 since different protocols may have varying implementation costs and 372 performance tradeoffs. However, to keep interoperability manageable, 373 a small number of specific, targeted, data transport protocols will 374 be identified and used. If a protocol is found to be suitable but 375 does not fully meet the requirements, then the protocol may need to 376 be extended. The following considerations should be taken into 377 account, although there might be trade-offs among these 378 considerations. 380 o The protocol(s) should support deployments with a very large 381 number of users without substantial increase to operational 382 complexity for the storage provider. 384 o The protocol(s) should be easy for application integration, 385 whether they want to use it for P2P applications (e.g. file- 386 sharing or streaming) or for other content distribution 387 applications. 389 4.2. Authorization 391 DECADE ensures that access to a user's in-network storage is subject 392 to authorization by that user. The authorization can take into 393 account the user trying to access, the content, the time period, etc. 395 4.3. Resource control 397 A user uses the IAP protocol to manage the resources on in-network 398 storage that can be used by other peers, e.g., network access to the 399 storage or network connections themselves. The resource control 400 policies could be based on individual remote peers or a whole 401 application. 403 5. Usage Scenarios 405 Usage scenarios are described from two perspectives. First, we 406 introduce high-level use cases showing how P2P applications may 407 utilize in-network storage. Second, we show how in more detail how 408 users exchange data using IAP. 410 5.1. BitTorrent 412 BitTorrent may be integrated with DECADE to be more network efficient 413 and reduce the bandwidth consumed on ISP networks. When a BitTorrent 414 client uploads a block to peers, the block traverses the last-mile 415 uplink once for each peer. With DECADE, however, the BitTorrent 416 client may upload the block to its in-network storage. Peers may 417 retrieve the block from the in-network storage, reducing the amount 418 of data on the last-mile uplink. 420 We now describe in more detail how BitTorrent can utilize DECADE. 421 For illustration, we assume that both the BitTorrent client (A) and 422 its peer (B) utilize in-network storage. When A requests a block, it 423 indicates that it would like the block stored in its in-network 424 storage and provides the necessary access control. Instead of 425 sending the 'piece' message with the desired block, peer B replies 426 with a 'redirect' message indicating that the content should be 427 retrieved from its own in-network storage and provides the necessary 428 access control. If the peer B had not previously stored the content 429 in its in-network storage, it uploads the block. A instructs its in- 430 network storage to download the block from B's in-network storage, 431 and finally A itself retrieves the block. 433 Note that this requires extensions to the BitTorrent protocol. While 434 there are multiple ways to do so, this example assumes the native 435 BitTorrent 'request' message is extended to carry additional 436 information and that a new 'redirect' message is added. Upload and 437 download to/from in-network storage uses the standard IAP protocol. 439 This example has illustrated how utilizing DECADE can increase 440 BitTorrent's network efficiency. First, notice that peer B does not 441 utilize any uplink bandwidth if the block was already present in its 442 in-network storage. Second, notice that the block is downloaded 443 directly into A's in-network storage. When A wishes to share the 444 block with another peer (say, peer C) that supports DECADE, it may 445 upload directly from its in-network storage, again avoiding usage of 446 the last-mile uplink. 448 Redirection to a DECADE server does not only need to come from a 449 peer. In this case, in order to avoid the connectivity issue brought 450 by NATs, B can also attach its in-network storage address in the 451 message to its tracker. When A sends the content request message 452 with the content ID to the tracker, the tracker replies with B's in- 453 network storage address and the BitMap info. Then A sends a request 454 using IAP protocol to B's in-network storage for the pieces of this 455 content, with the unique identity of the content in the storage. 457 This technique can be applied to other P2P applications as well. 458 Since P2P applications use a standard for communicating with in- 459 network storage, they no longer require in-network storage to 460 explicitly support their protocol. P2P applications retain the 461 ability to explicitly manage which content is placed in in-network 462 storage, as well as access and resource control polices. 464 5.2. Content Publisher 466 Content publishers may also utilize in-network storage. For example, 467 consider a P2P live streaming application. A content publisher 468 typically maintains a small number of sources, each of which 469 distributes blocks in the current play buffer to a set of the P2P 470 peers. 472 Consider a case where the content publisher owns an in-network 473 storage account within ISP A. If there are multiple P2P peers within 474 ISP A, the content publisher may utilize DECADE to distribute content 475 to the peers. 477 First, the content publisher stores a block in the in-network 478 storage, and then sends to each peer in ISP A the block's identifier 479 and necessary access control. Second, each peer may then download 480 from the content publisher's in-network storage. 482 In this example, the block is distributed in a more network efficient 483 way (the content only traverses the ISP's interdomain link once), 484 while the content publisher retains explicit control over access to 485 the content placed in its own storage. The content publisher can 486 remove content from its in-network storage when it is stale or needs 487 to be replaced, and grant access and resources to only the desired 488 peers. 490 Note that content publishers and individual peers can each use in- 491 network storage. For example, after downloading content from the 492 content publisher's in-network storage, peers may each utilize their 493 own in-networks storage similar to the usage scenario in Section 5.1. 494 This can have the benefit of increased network efficiency, while 495 content publishers and peers still retain control over content placed 496 in their own in-network storage. 498 If it desires, a content publisher may still apply DRM to the 499 payload. This is independent of any authentication or authorization 500 provided by DECADE. 502 5.3. CDN/P2P hybrid 504 Some applications use a hybrid content distribution approach 505 incorporating both P2P and CDN modes. As an example, Internet TV may 506 be implemented as a hybrid CDN/P2P application by distributing 507 content from central servers via a CDN, and also incorporating a P2P 508 mode amongst endhosts and set-top boxes. 510 DECADE may be beneficial to hybrid CDN/P2P applications as well. 511 However, if only the endhost can store content in the DECADE server, 512 the content must be downloaded and then uploaded over the last-mile 513 access link before another peer may retrieve it from a DECADE server. 514 Thus, in this deployment scenario, it may be advantageous for a 515 content publisher or CDN provider to store content on DECADE servers. 517 5.4. Data Transfer Scenarios 519 The previous usage scenarios have utilized the ability for peers to 520 transfer data by storing and retrieving from in-network storage. 521 This section describes in further detail an example solution of how 522 DECADE can provide this capability. It is important to note that 523 this example is provided to illustrate more concretely the 524 capabilities provided by DECADE, and is not intended to reflect any 525 particular solution methodology or protocol(s) developed by the 526 DECADE Working Group. 528 In this section, we consider the case of a user B (the receiver) 529 requesting data from user A (the sender). We use Sa to denote User 530 A's storage account, and Sb to denote User B's storage account. Each 531 user independently decides if its in-network storage account is used, 532 so there are four cases. 534 When a user indicates that it wishes to use its in-network storage, 535 it provides an access control token the other user. The token is 536 sent using the application's protocol. To simplify the illustration, 537 we omit details of the access control from the detailed scenarios 538 below. 540 5.4.1. Both Sender and Receiver Accounts are Used 542 This scenario is illustrated in Figure 2. B first requests an object 543 from A using the application protocol indicating it wishes the object 544 to be stored in Sb. A responds using the application protocol 545 indicating that B should download the object from Sa. B sends a IAP 546 request to Sb indicating that the object should be downloaded from 547 Sa. Sb uses IAP to download from Sa, and finally, B downloads the 548 object from Sb (also using IAP). 550 +-------+ 4. IAP Get +-------+ 551 | Sa | <----------+ Sb | 552 +-------+ *********>+-------+ 553 5. data transfer ^ * 554 3. IAP Get \ * 6. data transfer 555 1. App request \ v 556 +-------+<-------------------+-------+ 557 |User A | |User B | 558 +-------+------------------->+-------+ 559 2. App response 561 Figure 2: Usage Scenario 1 (Sender and receiver Accounts used) 563 5.4.2. Only Sender's Storage Account is Used 565 This scenario is illustrated in Figure 3. B requests an object from 566 A using the application protocol. A responds using the application 567 protocol indicating that B should download the object from Sa. 568 Finally, B sends a IAP request to Sa to download the object. 570 +-------+ 571 | Sa | 572 +-------+ < * 573 \ * 574 \ * 575 \ * 4. data transfer 576 3. IAP Get \ * 577 \ * 578 1. App request \ v 579 +-------+<-------------------+-------+ 580 |User A | |User B | 581 +-------+------------------->+-------+ 582 2. App response 584 Figure 3: Usage Scenario 2 (Sender account used) 586 5.4.3. Only Receiver's Storage Account is Used 588 This scenario is illustrated in Figure 4. B requests an object from 589 A using the application protocol indicating that it wishes the object 590 to be stored in Sb. A stores the object in Sb (using IAP), and 591 responds to B (using the application protocol) that it should 592 download from Sb. B uses IAP to download the object from Sb. 594 +---------+ 595 > | Sb | 596 2. / +---------+ 597 IAP Store / ^ * 598 / 4. IAP Get \ * 5. data transfer 599 / 1. App request \ v 600 +-------+<---------------+-------+ 601 |User A | |User B | 602 +-------+--------------->+-------+ 603 3. App response 605 Figure 4: Usage Scenario 3 (Receiver account used) 607 5.4.4. No Storage Accounts are Used 609 This scenario is illustrated in Figure 5. In this scenario, the 610 application protocol is used directly to send data. This scenario 611 applies with one of the peers does not support IAP, or neither of the 612 peers are using in-network storage. 614 1. App request 615 +-------+<-------------------+-------+ 616 |User A | ... ... ... |User B | 617 +-------+*******************>+-------+ 618 2. data transfer 620 Figure 5: Usage Scenario 4 ( No storage accounts used) 622 6. Security Considerations 624 There are multiple security considerations. We focus on two in this 625 section. 627 6.1. Denial of Service Attacks 629 Without access control or resource control, an attacker can try to 630 consume a large portion of the in-network storage, or exhaust the 631 connections of the in-network storage to commit a Denial of Service 632 (DoS) attack. Thus, access control and resource control mechanisms 633 are mandatory. A resource control mechanism should be used to allow 634 a user to allocate the resource in its in-network storage account to 635 be utilized by other clients. 637 6.2. Copyright and Legal Issues 639 Copyright and other laws may prevent the distribution of certain 640 content in various localities. While in-network storage operators 641 may adopt system-wide ingress or egress filters to implement 642 necessary policies for storing or retrieving content, and 643 applications may still apply DRM to the data stored in the network 644 storage, the specification and implementation of such policies (e.g., 645 filtering and DRM) is outside of the scope of this working group. 647 7. IANA Considerations 649 There is no IANA consideration with this document. 651 8. Acknowledgments 653 We would like to thank the following people for contributing to this 654 document: 656 David Bryan 658 Kar Ann Chew 660 Roni Even 662 Lars Eggert 664 Yingjie Gu 666 Francois Le Faucheur 668 Hongqiang Liu 670 Tao Ma 672 Borje Ohlman 674 Akbar Rahman 676 Yu-shun Wang 678 Richard Woundy 680 Yunfei Zhang 682 9. Informative References 684 [ipoque.com] 685 "http://www.ipoque.com/resources/internet-studies/ 686 internet-study-2008_2009". 688 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 689 Optimization (ALTO) Problem Statement", RFC 5693, 690 October 2009. 692 [I-D.weaver-alto-edge-caches] 693 Weaver, N., "Peer to Peer Localization Services and Edge 694 Caches", draft-weaver-alto-edge-caches-00 (work in 695 progress), March 2009. 697 [I-D.ietf-ppsp-problem-statement] 698 Zhang, Y., Zong, N., Camarillo, G., Seng, J., and Y. Yang, 699 "Problem Statement of P2P Streaming Protocol (PPSP)", 700 draft-ietf-ppsp-problem-statement-01 (work in progress), 701 January 2011. 703 [DCIA] http://www.dcia.info, "Distributed Computing Industry 704 Association". 706 [ipoque.P2P_survey.] 707 "Emerging Technologies Conference at MIT", Sept. 2007. 709 [P2P_file_sharing] 710 Parker, A., "The true picture of peer-to-peer 711 filesharing", July 2004. 713 [Octoshape] 714 "http://www.octoshape.com/?page=company/about". 716 [PPLive] "http://www.synacast.com/products/". 718 [ICNP] Wu, H., "Challenges and opportunities of Internet 719 developments in China, ICNP 2007 Keynote", Oct. 2007. 721 Appendix A. Other Related Work in IETF 723 Note that DECADE is independent of current IETF work on P2P, e.g. 724 P2PSIP, ALTO, and PPSP. For example, peers discovered by either 725 RELOAD or ALTO can all use DECADE to share data. 727 The Peer to Peer Streaming Protocol effort in the IETF is 728 investigating specification of signaling protocols (called PPSP 729 protocols) for multiple types of entities (e.g. intelligent 730 endpoints, caches, content distribution network nodes, and/or other 731 edge devices) to participate in P2P streaming systems in both fixed 732 and mobile Internet. As discussed in the PPSP problem statement 733 document [I-D.ietf-ppsp-problem-statement], one important PPSP use 734 case is the support of an in-network edge cache for P2P streaming. 735 However, this approach to providing in-network cache has different 736 applicability, different objectives and different implications for 737 the in-network cache operator. A DECADE service can be used for any 738 application transparently to the DECADE in-network storage operator: 739 it can be used for any P2P streaming application (whether it supports 740 PPSP protocols or not), for any other P2P application, and for non 741 P2P applications that simply want to benefit from in-network storage. 742 So with DECADE the operator is providing a generic in-network storage 743 service that can be used by any application without application 744 involvement or awareness by the operator; in the PPSP cache use case, 745 the cache operator is participating in the specific P2P streaming 746 service. 748 DECADE and PPSP can both contribute independently, and (where 749 appropriate) simultaneously, to making content available closer to 750 peers. Here are a number of example scenarios: 752 A given network supports DECADE in-network storage, and its CDN 753 nodes do not participate as PPSP peers for a given "stream" (e.g. 754 because no CDN arrangement has been put in place between the 755 content provider and the considered network provider). In that 756 case, PPSP Peers will all be "off-net" but will be able to use 757 DECADE in-network storage to exchange chunks. 759 A given network does not support DECADE in-network storage, and 760 (some of) its CDN nodes participate as PPSP peers for a given 761 "stream" (e.g. say because an arrangement has been put in place 762 between the content provider and the considered network provider). 763 In that case, the CDN nodes will participate as in-network PPSP 764 peers. The off-net PPSP peers (i.e., end users) will be able to 765 get chunks from the in-network CDN nodes (using PPSP protocols 766 with the CDN nodes). 768 A given network supports DECADE in-network storage, and (some of) 769 its CDN nodes participate as PPSP Peers for a given "stream" (e.g. 770 say because an arrangement has been put in place between the 771 content provider and the considered network provider). In that 772 case, the CDN nodes will participate as in-network PPSP Peers. 773 The off-net PPSP Peers (i.e., end users) will be able to get 774 chunks from the in-network CDN nodes (using PPSP protocols with 775 the CDN nodes) as well as be able to get chunks /share chunks 776 using DECADE in-network storage populated (using IAP protocol) by 777 PPSP peers (both off-net end-users and in-network CDN nodes). 779 PPSP and DECADE jointly to provide P2P streaming service for 780 heterogeneous networks including both fixed and mobile connections 781 and enables the mobile nodes to use DECADE. In this case there 782 may be some solutions to require more information in PPSP tracker 783 protocol, e.g., the mobile node can indicate its DECADE in-network 784 proxy to PPSP tracker and the following requesting peer can finish 785 its data transfer with the DECADE proxy with IAP. 787 Authors' Addresses 789 Haibin Song 790 Huawei 791 101 Software Avenue, Yuhua District, 792 Nanjing, Jiangsu Province 210012 793 China 795 Phone: +86-25-56624792 796 Email: haibin.song@huawei.com 798 Ning Zong 799 Huawei 800 101 Software Avenue, Yuhua District, 801 Nanjing, Jiangsu Province 210012 802 China 804 Phone: +86-25-56624760 805 Email: zongning@huawei.com 807 Y. Richard Yang 808 Yale University 810 Email: yry@cs.yale.edu 812 Richard Alimi 813 Google 815 Email: ralimi@google.com