idnits 2.17.1 draft-ietf-decade-problem-statement-01.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (December 18, 2010) is 4871 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) == Missing Reference: 'CNN' is mentioned on line 182, but not defined == Unused Reference: 'RFC3720' is defined on line 682, but no explicit reference was found in the text == Unused Reference: 'RFC5661' is defined on line 686, but no explicit reference was found in the text == Unused Reference: 'RFC2616' is defined on line 690, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 3720 (Obsoleted by RFC 7143) -- Obsolete informational reference (is this intentional?): RFC 5661 (Obsoleted by RFC 8881) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). 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: June 21, 2011 Y. Yang 6 Yale University 7 R. Alimi 8 Google 9 December 18, 2010 11 DECoupled Application Data Enroute (DECADE) Problem Statement 12 draft-ietf-decade-problem-statement-01 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 June 21, 2011. 48 Copyright Notice 49 Copyright (c) 2010 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. hybrid Internet TV . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . 12 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 attack . . . . . . . . . . . . . . . . . 14 85 6.2. Copyright and Legal issues . . . . . . . . . . . . . . . . 14 86 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 87 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 88 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 89 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 90 9.2. Informative References . . . . . . . . . . . . . . . . . . 15 91 Appendix A. Other Related Work in IETF . . . . . . . . . . . . . 16 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 94 1. Introduction 96 P2P applications, including both P2P streaming and P2P filesharing 97 applications, make up a large fraction of the traffic in many ISP 98 networks today. One way to reduce bandwidth usage by P2P 99 applications is to introduce storage capabilities in the networks. 100 Allowing P2P applications to store and retrieve data from inside 101 networks can reduce traffic on the last-mile uplink, as well as 102 backbone and transit links [I-D.weaver-alto-edge-caches]. 104 P2P caches provide in-network storage and have been deployed in some 105 networks. But the current P2P caching architecture poses challenges 106 to both P2P cache vendors and P2P application developers. For P2P 107 cache vendors, it is challenging to support a number of continuously 108 evolving P2P application protocols, due to lack of documentation, 109 ongoing protocol changes, and rapid introduction of new features by 110 P2P applications. For P2P applications, closed P2P caching systems 111 limit P2P applications to effectively utilize in-network storage. In 112 particular, P2P caches typically do not allow users to explicitly 113 store content into in-network storage. Neither do they allow users 114 to implement control over the content that have been placed into the 115 in-network storage. 117 Both of these challenges can be effectively addressed by using an 118 open, standard protocol to access in-network storage. P2P 119 applications can store and retrieve content in the in-network 120 storage, as well as control resources (e.g., bandwidth, connections) 121 consumed by peers in a P2P application. As a simple example, a peer 122 of a P2P application may upload to other peers through its in-network 123 storage, saving its usage of last-mile uplink bandwidth. 125 In this document, we distinguish between two functional components of 126 the native P2P application protocol: signaling and data access. 127 Signaling includes operations such as handshaking and discovering 128 peer and content availability. The data access component transfers 129 content from one peer to another. 131 With DECADE, P2P applications can still use their native protocols 132 for signaling and data transport. However, they may use a standard 133 protocol for data access incorporating in-network storage, and fall 134 back to their native data transport protocols if in-network storage 135 is not available or not used. 137 In essence, an open, standard protocol to access in-network storage 138 provides an alternative mechanism for P2P application data access 139 that is decoupled from P2P application control and signaling. This 140 decoupling leads to many advantages, which is explained further in 141 Section 4. 143 And further, either the existing P2P cache or any new type of in- 144 network storage should be deployed near the edge of the ISP's network 145 so as to gain better performance. 147 2. Terminology and Concepts 149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 150 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 151 document are to be interpreted as described in [RFC2119]. 153 The following terms have special meaning in the definition of the in- 154 network storage system. 156 In-network Storage: A service inside a network that provides 157 storage and bandwidth to network applications. In-network storage 158 may reduce upload/transit/backbone traffic and improve network 159 application performance. 161 IAP (In-network storage Access Protocol): a standard protocol that 162 is spoken between P2P applications and in-network storage. The 163 protocol may also be used between entities implementing the in- 164 network storage service. IAP may be a new protocol or existing 165 protocol with extensions. 167 P2P Cache (Peer to Peer Cache): a kind of in-network storage that 168 understands the signaling and transport of specific P2P 169 application protocols, it caches the content for those specific 170 p2p applications in order to serve peers and reduce traffic on 171 certain links. 173 Content Publisher: An entity that originates content to consumers. 175 3. The Problems 177 The emergence of peer-to-peer (P2P) as a major type of network 178 applications (esp. P2P file sharing and streaming apps) has led to 179 substantial opportunities. The P2P paradigm can be utilized in 180 designing highly scalable and robust applications at low cost, 181 compared with traditional client-server paradigms. For example, CNN 182 [CNN] reported that P2P streaming by Octoshape played a major role in 183 its distribution of the historical inauguration address of President 184 Obama. PPLive, one of the largest P2P streaming vendors, is able to 185 distribute large-scale, live streaming programs to more than 2 186 million users with only a handful of servers. 188 However, P2P applications also face substantial design challenges. A 189 particular problem facing P2P applications is the substantial stress 190 that they place on the network infrastructure. Also, lacking of 191 infrastructure support can lead to unstable P2P application 192 performance during peer churns and flash crowd. Here flash crowd 193 means a large group of application users begin to acess the same 194 service during a very short period of time, which is a chanllenge to 195 the system. Below we elaborate on the problems in more detail. 197 3.1. P2P infrastructural stress and inefficiency 199 A particular problem of the P2P paradigm is the stress that P2P 200 application traffic places on the infrastructure of Internet service 201 providers (ISP). Multiple measurements (e.g., [ipoque]) have shown 202 that P2P traffic has become a major type of traffic on some networks. 203 Furthermore, network-agnostic peering leads to unnecessary traversal 204 across network domains or spanning the backbone of a network, leading 205 to network inefficiency [RFC5693]. 207 Recently, the IETF Application Layer Traffic Optimization (ALTO) 208 Working Group was formed to provide P2P applications with network 209 information so that they can perform better-than-random initial peer 210 selection [RFC5693]. However, there are limitations on what ALTO can 211 achieve alone. For example, network information alone cannot reduce 212 P2P traffic in access networks, as the total access upload traffic is 213 equal to the total access download traffic in a pure P2P system. On 214 the other hand, it is reported that P2P traffic is becoming the 215 dominating traffic on the access networks of some networks, reaching 216 as high as 50-60% at the down-links and 60-90% at the uplinks 217 ([DCIA], [ICNP], [ipoque.P2P_survey.], [P2P_file_sharing]). 218 Consequently, it becomes increasingly important to complement the 219 ALTO effort and reduce upload access traffic, in addition to cross- 220 domain and backbone traffic. 222 The IETF Low Extra Delay Background Transport (LEDBAT) Working Group 223 is focusing on techniques that allow large amounts of data to be 224 consistently transmitted without substantially affecting the delays 225 experienced by other users and applications. It is expected that 226 some P2P applications would start using such techniques, thereby 227 somewhat alleviating the perceivable impact (at least on other 228 applications) of their high volume traffic . However, such 229 techniques may not be adopted by all P2P applications. Also, when 230 adopted, these techniques do not remove all inefficiencies, such as 231 those associated with traffic being sent upstream as many times as 232 there are remote peers interested in getting the corresponding 233 information. For example, the P2P application transfer completion 234 times remain affected by potential (relatively) slow upstream 235 transmission. Similarly, the performance of real-time P2P 236 applications may be affected by potential (relatively) higher 237 upstream latencies. 239 3.2. P2P cache: a complex in-network storage 241 An effective technique to reduce P2P infrastructural stress and 242 inefficiency is to introduce in-network storage. For example, in 243 [I-D.weaver-alto-edge-caches], the author demonstrates clearly the 244 potential benefits of introducing in-network storage to improve 245 network efficiency and thus reduce network infrastructure stress. 247 In the current Internet, in-network storage is introduced as P2P 248 caches, either transparently or explicitly as a P2P peer. To provide 249 service to a specific P2P application, the P2P cache server must 250 support the specific signaling and transport protocols of the 251 specific P2P application. This can lead to substantial complexity 252 for the P2P Cache vendor. 254 First, there are many P2P applications on the Internet (e.g., 255 BitTorrent, eMule, Flashget, and Thunder for file sharing; Abacast, 256 Kontiki, Octoshape, PPLive, PPStream, and UUSee for P2P streaming). 257 Consequently, a P2P cache vendor faces the challenge of supporting a 258 large number of P2P application protocols, leading to product 259 complexity and increased development cost. 261 Furthermore, a specific P2P application protocol may be evolving 262 continuously, to add new features or fix bugs. This forces a P2P 263 cache vendor to continuously update to track the changes of the P2P 264 application, leading to product complexity, high cost, and low 265 reliability. 267 Third, many P2P applications use proprietary protocols or support 268 end-to-end encryption. This can render P2P caches ineffective. 270 3.3. Ineffective integration of P2P applications 272 As P2P applications evolve, it becomes increasingly clear that they 273 will need in-network resources to provide positive user experiences. 274 For example, multiple P2P streaming systems seek additional in- 275 network resources during flash crowd, such as just before a major 276 live streaming event. In asymmetric networks when the aggregated 277 upload bandwidth of a channel cannot meet the download demand, a P2P 278 application may seek additional in-network resources to maintain a 279 stable system. 281 A requirement by some P2P applications in using in-network 282 infrastructural resources, however, is flexibility in implementing 283 resource allocation policies. A major competitive advantage of many 284 successful P2P systems is their substantial expertise in how to most 285 efficiently utilize peer and infrastructural resources. For example, 286 many live P2P systems have their specific algorithms in selecting the 287 peers that behave as the more stable, higher bandwidth sources. They 288 continue to fine-tune such algorithms. In other words, in-network 289 storage should export basic mechanisms and allow as much flexibility 290 as possible to P2P applications to implement specific policies. This 291 conforms to the end-to-end systems principle and allows innovation 292 and satisfaction of specific business goals. Existing techniques for 293 P2P application in-network storage lack these capabilities. 295 4. DECADE as an In-network Storage Capability 297 The objective of this working group is to design DECADE, an in- 298 network storage protocol to address the problems discussed in the 299 preceding section. 301 DECADE will provide access to storage and data transport services in 302 the network to P2P applications to improve their efficiency and 303 reduce the stress on the network infrastructure. Unlike the existing 304 P2P caching architecture, DECADE is a standard interface for various 305 P2P applications (both content publishers and end users) to access 306 in-network storage. This decoupling of P2P data access from P2P 307 application control and signaling reduces the complexity of in- 308 network storage services. Furthermore, DECADE provides basic access 309 mechanisms and allows P2P applications to implement flexible policies 310 to create an ecosystem for application innovation and various 311 business goals. Besides that, it also improves the availability of 312 P2P contents because the in-network storage is always-on. 314 IAP 315 -----------+ 316 | | 317 | v 318 +--------------------+ 319 | In-network Storage | 320 +--------------------+ 321 ^ ^ 322 IAP | IAP | 323 +-------------v-+ +-v-------------+ 324 | P2P | | Content | 325 | application | | publishers | 326 | clients | +---------------+ 327 +---------------+ 328 | ^ 329 | | 330 +-------------+ 331 P2P application 332 native protocol 334 Figure 1 Overview of protocol interaction between DECADE elements 336 Specifically, the main component of DECADE is the in-network storage 337 access protocol (IAP), which is a standard, P2P-application-agnostic 338 protocol for different P2P applications to access in-network storage. 339 IAP defines a set of commands that P2P application elements can issue 340 to in-network storage to store and retrieve data. IAP includes the 341 following functionalities: 343 (1) Data access provides read/write by users (e.g., P2P application 344 clients and content publishers) to the corresponding in-network 345 storage and between entities implementing the in-network storage; 347 (2) Authorization implements access control to resources provided by 348 in-network storage; 350 (3) Resource control allows users to implement application policies 351 for the corresponding in-network storage. 353 While DECADE will focus on P2P applications, the solution is expected 354 to be applicable in other contexts with similar requirements. 356 4.1. Data access 358 P2P application clients use the protocol to read data from an in- 359 network storage, store data to an in-network storage, or remove data 360 from an in-network storage. The data could be of various types. 361 Existing protocols will be used wherever possible and appropriate to 362 support DECADE's requirements. In particular, data storage, 363 retrieval, and management may be provided by an existing IETF 364 protocols. The WG will not limit itself to a single data transport 365 protocol since different protocols may have varying implementation 366 costs and performance tradeoffs. However, to keep interoperability 367 manageable, a small number of specific, targeted, data transport 368 protocols will be identified and used. If a protocol is found to be 369 suitable but does not fully meet the requirements, then the protocol 370 may need to be extended. The following considerations should be 371 taken into account. But it might be a trade-off when making 372 decision. 374 o The protocol(s) should support deployments with a very large 375 number of users without substantial increase to operational 376 complexity for the storage provider. 378 o The protocol(s) should be easy for applications to integrate 379 with when they want to use it for P2P applications (e.g. file- 380 sharing or streaming) or other content distribution applications. 382 4.2. Authorization 384 DECADE ensures that access to the in-network storage is subject to 385 authorization by the user owning the in-network storage service. The 386 authorization can take into account the user trying to access, the 387 content, the time period, etc. 389 4.3. Resource control 391 A user uses the protocol to manage the resources on in-network 392 storage that can be used by other peers, e.g., the bandwidth or 393 connections. The resource control policies could be based on 394 individual remote peers or a whole application. 396 5. Usage Scenarios 398 Usage scenarios are described from two perspectives. First, we 399 introduce high-level use cases showing how P2P applications may 400 utilize in-network storage. Second, we show how in more detail how 401 users exchange data using IAP. 403 5.1. BitTorrent 405 BitTorrent may be integrated with DECADE to be more network efficient 406 and reduce the bandwidth consumed on ISP networks. When a BitTorrent 407 client uploads a block to peers, the block traverses the last-mile 408 uplink once for each peer. With DECADE, however, the BitTorrent 409 client may upload the block to its in-network storage. Peers may 410 retrieve the block from the in-network storage, reducing the amount 411 of data on the last-mile uplink. 413 We now describe in more detail how BitTorrent can utilize DECADE. 414 For illustration, we assume that both the BitTorrent client (A) and 415 its peer (B) utilize in-network storage. When A requests a block, it 416 indicates that it would like the block stored in its in-network 417 storage and provides the necessary access control. Instead of 418 sending the 'piece' message with the desired block, peer B replies 419 with a 'redirect' message indicating that the content should be 420 retrieved from its own in-network storage and provides the necessary 421 access control. If the peer B had not previously stored the content 422 in its in-network storage, it uploads the block. A downloads the 423 block into its own in-network storage from B's in-network storage, 424 and finally A itself retrieves the block. 426 Note that this requires extensions to the BitTorrent protocol. While 427 there are multiple ways to do so, this example assumes the native 428 BitTorrent 'request' message is extended to carry additional 429 information and that a new 'redirect' message is added. Upload and 430 download to/from in-network storage uses the standard IAP protocol. 432 This example has illustrated how utilizing DECADE can increase 433 BitTorrent's network efficiency. First, notice that peer B does not 434 utilize any uplink bandwidth if the block was already present in its 435 in-network storage. Second, notice that the block is downloaded 436 directly into A's in-network storage. When A wishes to share the 437 block with another peer (say, peer C) that supports DECADE, it may 438 upload directly from its in-network storage, again avoiding usage of 439 the last-mile uplink. 441 In this case, in order to avoid the connectivity issue brought by 442 NATs, B can also attach its in-network storage address in the message 443 to its tracker. When A sends the content request message with the 444 content ID to the tracker, the tracker replies with B's in-network 445 storage address and the BitMap info. Then A sends a request using 446 IAP protocol to B's in-network storage for the pieces of this 447 content, with the unique identities of these pieces in the storage. 449 This technique can be applied to other P2P applications as well. 450 Since P2P applications use a standard for communicating with in- 451 network storage, they no longer require in-network storage to 452 explicitly support their protocol. P2P applications retain the 453 ability to explicitly manage which content is placed in in-network 454 storage, as well as access and resource control polices. 456 5.2. Content Publisher 458 Content Publishers may also utilize in-network storage. For example, 459 consider a P2P live streaming application. A Content Publisher 460 typically maintains a small number of sources, each of which 461 distributes blocks in the current play buffer to a set of the P2P 462 peers. 464 Consider a case where the Content Publisher owns an in-network 465 storage account within ISP A. If there are multiple P2P peers within 466 ISP A, the Content Publisher may utilize DECADE to distribute content 467 to the peers. 469 First, the Content Publisher stores a block in the in-network 470 storage, and then sends to each peer in ISP A the block's identifier 471 and necessary access control. Second, each peer may then download 472 from the Content Publisher's in-network storage. 474 In this example, the block is distributed in a more network efficient 475 way (the content only traverses the ISP's interdomain link once), 476 while the Content Publisher retains explicit control over access to 477 the content placed in its own storage. The Content Publisher can 478 remove content from its in-network storage when it is stale or needs 479 to be replaced, and grant access and resources to only the desired 480 peers. 482 Note that Content Publishers and individual peers can each use in- 483 network storage. For example, after downloading content from the 484 Content Publisher's in-network storage, peers may each utilize their 485 own in-networks storage similar to the usage scenario in Section 5.1. 486 This can have the benefit of increased network efficiency, while 487 Content Publishers and peers still retain control over content placed 488 in their own in-network storage. 490 5.3. hybrid Internet TV 492 A particular interesting Internet TV variant is "hybrid Internet TV" 493 based on an Internet TV distribution service that is a hybrid between 494 traditional CDN and a P2P service. Such a service would distribute 495 content from central servers, make use of CDN caches on the way and 496 finally use the end hosts/STB as caches for the P2P part of the 497 application. If only the P2P application in the host/STB can store 498 content in the DECADE storage, the content first has to be downloaded 499 from the Internet TV server/CDN cache over the access link to the 500 host/STB and then uploaded, over the same access link, to the DECADE 501 storage before any peer in the P2P part of the application can access 502 it from the DECADE storage (instead of downloading it from the 503 client). 505 5.4. Data Transfer Scenarios 507 The previous usage scenarios have utilized the ability for peers to 508 transfer data by storing and retrieving from in-network storage. 509 This section describes in further detail an example solution of how 510 DECADE can provide this capability. 512 In this section, we consider the case of a user B (the receiver) 513 requesting data from user A (the sender). We use Sa to denote User 514 A's storage account, and Sb to denote User B's storage account. Each 515 user independently decides if its in-network storage account is used, 516 so there are four cases. 518 When a user indicates that it wishes to use its in-network storage, 519 it provides an access control token the other user. The token is 520 sent using the application's protocol. To simplify the illustration, 521 we omit details of the access control from the detailed scenarios 522 below. 524 5.4.1. Both Sender and Receiver Accounts are Used 526 This scenario is illustrated in Figure 2. B first requests an object 527 from A using the application protocol indicating it wishes the object 528 to be stored in Sb. A responds using the application protocol 529 indicating that B should download the object from Sa. B sends a IAP 530 request to Sb indicating that the object should be downloaded from 531 Sa. Sb uses IAP to download from Sa, and finally, B downloads the 532 object from Sb (also using IAP). 534 +-------+ 4 IAP Get +-------+ 535 | Sa | <----------+ Sb | 536 +-------+ *********>+-------+ 537 5 data transfer ^ * 538 3 IAP Get \ * 6 data transfer 539 1 App request \ \ / 540 +-------+<-------------------+-------+ 541 |User A | |User B | 542 +-------+------------------->+-------+ 543 2 App response 545 Figure 2: Usage Scenario 1 (Sender and receiver Accounts used) 547 5.4.2. Only Sender's Storage Account is Used 549 This scenario is illustrated in Figure 3. B requests an object from 550 A using the application protocol. A responds using the application 551 protocol indicating that B should download the object from Sa. 552 Finally, B sends a IAP request to Sa to download the object. 554 +-------+ 555 | Sa | 556 +-------+ 557 ^ * 558 3 IAP Get \ * 4 data transfer 559 1 App request \ \/ 560 +-------+<-------------------+-------+ 561 |User A | |User B | 562 +-------+------------------->+-------+ 563 2 App response 565 Firgure 3: Usage Scenario 2 (Sender account used) 567 5.4.3. Only Receiver's Storage Account is Used 569 This scenario is illustrated in Figure 4. B requests an object from 570 A using the application protocol indicating that it wishes the object 571 to be stored in Sb. A stores the object in Sb (using IAP), and 572 responds to B (using the application protocol) that it should 573 download from Sb. B uses IAP to download the object from Sb. 574 +---------+ 575 > | Sb | 576 3. / +---------+ 577 IAP Store / ^ * 578 / 3.IAP Get \ * 4 data transfer 579 / 1.App request \ \/ 580 +-------+<-------------------+-------+ 581 |User A | |User B | 582 +-------+------------------->+-------+ 583 2.App response 585 Figure 4: Usage Scenario 3 (Receiver account used) 587 5.4.4. No Storage Accounts are Used 589 This scenario is illustrated in Figure 5. In this scenario, the 590 application protocol is used directly to send data. This scenario 591 applies with one of the peers does not support IAP, or neither of the 592 peers are using in-network storage. 594 1.App request 595 +-------+<-------------------+-------+ 596 |User A | ... ... ... |User B | 597 +-------+*******************>+-------+ 598 2.data transfer 600 Figure 5: Usage Scenario 4 ( No storage accounts used) 602 6. Security Considerations 604 There are multiple security considerations. We focus on two in this 605 section. 607 6.1. Denial of Service attack 609 Without access control or resource control, an attacker can try to 610 consume a large portion of the in-network storage, or exhaust the 611 connections of the in-network storage to commit a Denial of Service 612 (DoS) attack. Thus, access control and resource control mechanisms 613 are mandatory. A resource control mechanism should be used to allow 614 a user to allocate the resource in its in-network storage account to 615 be utilized by other clients. 617 6.2. Copyright and Legal issues 619 Copyright and other laws may prevent the distribution of certain 620 content in various localities. While in-network storage operators 621 may adopt system-wide ingress or egress filters to implement 622 necessary policies for storing or retrieving content, the 623 specification and implementation of such policies (e.g., filtering 624 and DRM) is outside of the scope of this working group. 626 7. IANA Considerations 628 There is no IANA consideration with this document. 630 8. Acknowledgments 632 We would like to thank the following people for contributing to this 633 document: 635 Akbar Rahman 637 David Bryan 639 Francois Le Faucheur 641 Hongqiang Law. 643 Kar Ann Chew 645 Richard Woundy 647 Roni Even 648 Yunfei Zhang 650 Yu-shun Wang 652 Yingjie Gu 654 9. References 656 9.1. Normative References 658 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 659 Requirement Levels", BCP 14, RFC 2119, March 1997. 661 9.2. Informative References 663 [ipoque.com] 664 "http://www.ipoque.com/resources/internet-studies/ 665 internet-study-2008_2009". 667 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 668 Optimization (ALTO) Problem Statement", RFC 5693, 669 October 2009. 671 [I-D.weaver-alto-edge-caches] 672 Weaver, N., "Peer to Peer Localization Services and Edge 673 Caches", draft-weaver-alto-edge-caches-00 (work in 674 progress), March 2009. 676 [I-D.zhang-ppsp-problem-statement] 677 Zhang, Y., Zong, N., Camarillo, G., Seng, J., and Y. Yang, 678 "Problem Statement of P2P Streaming Protocol (PPSP)", 679 draft-zhang-ppsp-problem-statement-06 (work in progress), 680 July 2010. 682 [RFC3720] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M., 683 and E. Zeidner, "Internet Small Computer Systems Interface 684 (iSCSI)", RFC 3720, April 2004. 686 [RFC5661] Shepler, S., Eisler, M., and D. Noveck, "Network File 687 System (NFS) Version 4 Minor Version 1 Protocol", 688 RFC 5661, January 2010. 690 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 691 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 692 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 694 [DCIA] http://www.dcia.info, "Distributed Computing Industry 695 Association". 697 [ipoque.P2P_survey.] 698 "Emerging Technologies Conference at MIT", Sept. 2007. 700 [P2P_file_sharing] 701 Parker, A., "The true picture of peer-to-peer 702 filesharing", July 2004. 704 [ICNP] Wu, H., "Challenges and opportunities of Internet 705 developments in China, ICNP 2007 Keynote", Oct. 2007. 707 Appendix A. Other Related Work in IETF 709 Note that DECADE is independent of current IETF work on P2P, e.g. 710 P2PSIP, ALTO, PPSP. For example, peers discovered by either RELOAD 711 or ALTO can all use DECADE to share data. 713 The Peer to Peer Streaming Protocol effort in the IETF is 714 investigating specification of signaling protocols (called PPSP 715 protocols) for multiple types of entities (e.g. intelligent 716 endpoints, caches, content distribution network nodes, and/or other 717 edge devices) to participate in P2P streaming systems in both fixed 718 and mobile Internet. As discussed in the PPSP problem statement 719 document [I-D.zhang-ppsp-problem-statement], one important PPSP use 720 case is the support of an in-network edge Cache for P2P Streaming. 721 However, this approach to providing in-network cache has different 722 applicability, different objectives and different implications for 723 the in-network cache operator. A DECADE service can be used for any 724 application transparently to the DECADE in-network storage operator: 725 it can be used for any P2P Streaming application (whether it supports 726 PPSP protocols or not), for any other P2P application, and for non 727 P2P applications that simply want to benefit from in-network storage. 728 So with DECADE the operator is providing a generic in-network storage 729 service that can be used by any application without application 730 involvement or awareness by the operator; in the PPSP cache use case, 731 the cache operator is participating in the specific P2P streaming 732 service. 734 DECADE and PPSP can both contribute independently, and (where 735 appropriate) simultaneously, to making content available closer to 736 peers. Here are a number of example scenarios: 738 A given network supports DECADE in-network storage, and its CDN 739 nodes do not participate as PPSP Peers for a given "stream" (e.g. 740 say because no CDN arrangement has been put in place between the 741 Content Provider and the considered network provider). In that 742 case, PPSP Peers will all be "off-net" but will be able to use 743 DECADE in-network storage to exchange chunks. 745 A given network does not support DECADE in-network storage, and 746 (some of) its CDN nodes participate as PPSP Peers for a given 747 "stream" (e.g. say because an arrangement has been put in place 748 between the Content Provider and the considered network provider). 749 In that case, the CDN nodes will participate as in-network PPSP 750 Peers. The off-net PPSP Peers (ie end users) will be able to get 751 chunks from the in-network CDN nodes (using PPSP protocols with 752 the CDN nodes). 754 A given network supports DECADE in-network storage, and (some of) 755 its CDN nodes participate as PPSP Peers for a given "stream" (e.g. 756 say because an arrangement has been put in place between the 757 Content Provider and the considered network provider). In that 758 case, the CDN nodes will participate as in-network PPSP Peers. 759 The off-net PPSP Peers (ie end users) will be able to get chunks 760 from the in-network CDN nodes (using PPSP protocols with the CDN 761 nodes) as well as be able to get chunks /share chunks using DECADE 762 in-network storage populated (using IAP protocol) by PPSP Peers 763 (both off-net end-users and in-network CDN Nodes). 765 PPSP and DECADE jointly to provide P2P streaming service for 766 hetergeneous networks including both fixed and mobile connections 767 and enables the mobile nodes to use DECADE. In this case there 768 may be some solutions to require more information in PPSP tracker 769 protocol, e.g.,the mobile node can indicate its DECADE in-network 770 proxy to PPSP tracker and the following requesting peer can finish 771 data transfer with the DECADE proxy with IAP. 773 Authors' Addresses 775 Haibin Song 776 Huawei 777 101 Software Avenue, Yuhua District, 778 Nanjing, Jiangsu Province 210012 779 China 781 Phone: +86-25-56624792 782 Email: haibin.song@huawei.com 783 Ning Zong 784 Huawei 785 101 Software Avenue, Yuhua District, 786 Nanjing, Jiangsu Province 210012 787 China 789 Phone: +86-25-56624760 790 Email: zongning@huawei.com 792 Y. Richard Yang 793 Yale University 795 Email: yry@cs.yale.edu 797 Richard Alimi 798 Google 800 Email: rich@velvetsea.net