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