idnits 2.17.1 draft-ietf-decade-problem-statement-00.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 (August 24, 2010) is 4995 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 176, but not defined == Unused Reference: 'RFC3720' is defined on line 707, but no explicit reference was found in the text == Unused Reference: 'RFC5661' is defined on line 711, but no explicit reference was found in the text == Unused Reference: 'RFC2616' is defined on line 715, 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: February 25, 2011 Y. Yang 6 R. Alimi 7 Yale University 8 August 24, 2010 10 DECoupled Application Data Enroute (DECADE) Problem Statement 11 draft-ietf-decade-problem-statement-00 13 Abstract 15 Peer-to-peer (P2P) applications have become widely used on the 16 Internet today and make up a large portion of the traffic in many 17 networks. In P2P applications, one technique for reducing the total 18 amount of P2P traffic is to introduce storage capabilities within the 19 network. Traditional caches (e.g., P2P and Web caches) provide such 20 storage, but they are complex (due to explicitly supporting 21 individual P2P application protocols) and they do not allow users to 22 manage access to content in the cache. For example, Content 23 Providers cannot easily control access and resource usage policies to 24 satisfy their own requirements. This document discusses the 25 introduction of in-network storage for P2P applications, shows the 26 need for a standard protocol for accessing this storage, and 27 identifies the scope of this protocol. The accessing protocol can 28 also be used by other applications with similar requirements. 30 Status of this Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on February 25, 2011. 47 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Terminology and Concepts . . . . . . . . . . . . . . . . . . . 4 65 3. The Problems . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3.1. P2P infrastructural stress and inefficiency . . . . . . . 5 67 3.2. P2P cache: a complex in-network storage . . . . . . . . . 5 68 3.3. Ineffective integration of P2P applications and 69 in-network storage . . . . . . . . . . . . . . . . . . . . 6 70 4. DECADE as an In-network Storage Capability . . . . . . . . . . 7 71 4.1. Data access . . . . . . . . . . . . . . . . . . . . . . . 9 72 4.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 10 73 4.3. Resource control . . . . . . . . . . . . . . . . . . . . . 10 74 5. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 10 75 5.1. BitTorrent . . . . . . . . . . . . . . . . . . . . . . . . 10 76 5.2. Content Publisher . . . . . . . . . . . . . . . . . . . . 11 77 5.3. Data Transfer Scenarios . . . . . . . . . . . . . . . . . 12 78 5.3.1. Both Sender and Receiver Accounts are Used . . . . . . 12 79 5.3.2. Only Sender's Storage Account is Used . . . . . . . . 13 80 5.3.3. Only Receiver's Storage Account is Used . . . . . . . 13 81 5.3.4. No Storage Accounts are Used . . . . . . . . . . . . . 13 82 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 83 6.1. Denial of Service attack . . . . . . . . . . . . . . . . . 14 84 6.2. Copyright and Legal issues . . . . . . . . . . . . . . . . 14 85 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 86 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 87 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 88 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 89 9.2. Informative References . . . . . . . . . . . . . . . . . . 15 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 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 96 Internet 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. Neither do they allow users 112 to implement control over the content that have been placed into the 113 in-network storage. 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 With DECADE, P2P applications can still use their native protocols 130 for signaling and data transport. However, they may use a standard 131 protocol for data access incorporating in-network storage, and fall 132 back to their native data transport protocols if in-network storage 133 is not available or not used. 135 In essence, an open, standard protocol to access in-network storage 136 provides an alternative mechanism for P2P application data access 137 that is decoupled from P2P application control and signaling. This 138 decoupling leads to many advantages, which is explained further in 139 Section 4. 141 2. Terminology and Concepts 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in [RFC2119]. 147 The following terms have special meaning in the definition of the in- 148 network storage system. 150 In-network Storage: A service inside a network that provides 151 storage and bandwidth to network applications. In-network storage 152 may reduce upload/transit/backbone traffic and improve network 153 application performance. 155 IAP (In-network storage Access Protocol): a standard protocol that 156 is spoken between P2P applications and in-network storage. The 157 protocol may also be used between entities implementing the in- 158 network storage service. IAP may be a new protocol or existing 159 protocol with extensions. 161 P2P Cache (Peer to Peer Cache): a kind of in-network storage that 162 understands the signaling and transport of specific P2P 163 application protocols, it caches the content for those specific 164 p2p applications in order to serve peers and reduce traffic on 165 certain links. 167 Content Publisher: An entity that originates content to consumers. 169 3. The Problems 171 The emergence of peer-to-peer (P2P) as a major type of network 172 applications (esp. P2P file sharing and streaming apps) has led to 173 substantial opportunities. The P2P paradigm can be utilized in 174 designing highly scalable and robust applications at low cost, 175 compared with traditional client-server paradigms. For example, CNN 176 [CNN] reported that P2P streaming by Octoshape played a major role in 177 its distribution of the historical inauguration address of President 178 Obama. PPLive, one of the largest P2P streaming vendors, is able to 179 distribute large-scale, live streaming programs to more than 2 180 million users with only a handful of servers. 182 However, P2P applications also face substantial design challenges. A 183 particular problem facing P2P applications is the substantial stress 184 that they place on the network infrastructure. Also, lacking of 185 infrastructure support can lead to unstable P2P application 186 performance during peer churns and flash crowd. Below we elaborate 187 on the problems in more detail. 189 3.1. P2P infrastructural stress and inefficiency 191 A particular problem of the P2P paradigm is the stress that P2P 192 application traffic places on the infrastructure of Internet service 193 providers (ISP). Multiple measurements (e.g., [ipoque]) have shown 194 that P2P traffic has become a major type of traffic on some networks. 195 Furthermore, network-agnostic peering leads to unnecessary traversal 196 across network domains or spanning the backbone of a network, leading 197 to network inefficiency [I-D.ietf-alto-problem-statement]. 199 Recently, the IETF Application Layer Traffic Optimization (ALTO) 200 Working Group was formed to provide P2P applications with network 201 information so that they can perform better-than-random initial peer 202 selection [I-D.ietf-alto-problem-statement]. However, there are 203 limitations on what ALTO can achieve alone. For example, network 204 information alone cannot reduce P2P traffic in access networks, as 205 the total access upload traffic is equal to the total access download 206 traffic in a pure P2P system. On the other hand, it is reported that 207 P2P traffic is becoming the dominating traffic on the access networks 208 of some networks, reaching as high as 50-60% at the down-links and 209 60-90% at the uplinks ([DCIA], [ICNP], [ipoque.P2P_survey.], 210 [P2P_file_sharing]). Consequently, it becomes increasingly important 211 to complement the ALTO effort and reduce upload access traffic, in 212 addition to cross-domain and backbone traffic. 214 The IETF Low Extra Delay Background Transport (LEDBAT) Working Group 215 is focusing on techniques that allow large amounts of data to be 216 consistently transmitted without substantially affecting the delays 217 experienced by other users and applications. It is expected that 218 some P2P applications would start using such techniques, thereby 219 somewhat alleviating the perceivable impact (at least on other 220 applications) of their high volume traffic . However, such 221 techniques may not be adopted by all P2P applications. Also, when 222 adopted, these techniques do not remove all inefficiencies, such as 223 those associated with traffic being sent upstream as many times as 224 there are remote peers interested in getting the corresponding 225 information. For example, the P2P application transfer completion 226 times remain affected by potential (relatively) slow upstream 227 transmission. Similarly, the performance of real-time P2P 228 applications may be affected by potential (relatively) higher 229 upstream latencies. 231 3.2. P2P cache: a complex in-network storage 233 An effective technique to reduce P2P infrastructural stress and 234 inefficiency is to introduce in-network storage. For example, in 235 [I-D.weaver-alto-edge-caches], the author demonstrates clearly the 236 potential benefits of introducing in-network storage to improve 237 network efficiency and thus reduce network infrastructure stress. 239 In the current Internet, in-network storage is introduced as P2P 240 caches, either transparently or explicitly as a P2P peer. To provide 241 service to a specific P2P application, the P2P cache server must 242 support the specific signaling and transport protocols of the 243 specific P2P application. This can lead to substantial complexity 244 for the P2P Cache vendor. 246 First, there are many P2P applications on the Internet (e.g., 247 BitTorrent, eMule, Flashget, and Thunder for file sharing; Abacast, 248 Kontiki, Octoshape, PPLive, PPStream, and UUSee for P2P streaming). 249 Consequently, a P2P cache vendor faces the challenge of supporting a 250 large number of P2P application protocols, leading to product 251 complexity and increased development cost. 253 Furthermore, a specific P2P application protocol may be evolving 254 continuously, to add new features or fix bugs. This forces a P2P 255 cache vendor to continuously update to track the changes of the P2P 256 application, leading to product complexity, high cost, and low 257 reliability. 259 Third, many P2P applications use proprietary protocols or support 260 end-to-end encryption. This can render P2P caches ineffective. 262 3.3. Ineffective integration of P2P applications and in-network storage 264 As P2P applications evolve, it becomes increasingly clear that they 265 will need in-network resources to provide positive user experiences. 266 For example, multiple P2P streaming systems seek additional in- 267 network resources during flash crowd, such as just before a major 268 live streaming event. In asymmetric networks when the aggregated 269 upload bandwidth of a channel cannot meet the download demand, a P2P 270 application may seek additional in-network resources to maintain a 271 stable system. 273 A requirement by some P2P applications in using in-network 274 infrastructural resources, however, is flexibility in implementing 275 resource allocation policies. A major competitive advantage of many 276 successful P2P systems is their substantial expertise in how to most 277 efficiently utilize peer and infrastructural resources. For example, 278 many live P2P systems have their specific algorithms in selecting the 279 peers that behave as the more stable, higher bandwidth sources. They 280 continue to fine-tune such algorithms. In other words, in-network 281 storage should export basic mechanisms and allow as much flexibility 282 as possible to P2P applications to implement specific policies. This 283 conforms to the end-to-end systems principle and allows innovation 284 and satisfaction of specific business goals. Existing techniques for 285 P2P application in-network storage lack these capabilities. 287 4. DECADE as an In-network Storage Capability 289 The objective of this working group is to design DECADE, an in- 290 network storage protocol to address the problems discussed in the 291 preceding section. 293 DECADE will provide access to storage and data transport services in 294 the network to P2P applications to improve their efficiency and 295 reduce the stress on the network infrastructure. Unlike the existing 296 P2P caching architecture, DECADE is a standard interface for various 297 P2P applications (both content publishers and end users) to access 298 in-network storage. This decoupling of P2P data access from P2P 299 application control and signaling reduces the complexity of in- 300 network storage services. Furthermore, DECADE provides basic access 301 mechanisms and allows P2P applications to implement flexible policies 302 to create an ecosystem for application innovation and various 303 business goals. Besides that, it also improves the availability of 304 P2P contents because the in-network storage is always-on. 306 IAP 307 -----------+ 308 | | 309 | v 310 +--------------------+ 311 | In-network Storage | 312 +--------------------+ 313 ^ ^ 314 IAP | IAP | 315 +-------------v-+ +-v-------------+ 316 | P2P | | Content | 317 | application | | publishers | 318 | clients | +---------------+ 319 +---------------+ 320 | ^ 321 | | 322 +-------------+ 323 P2P application 324 native protocol 326 Figure 1 Overview of protocol interaction between DECADE elements 328 Specifically, the main component of DECADE is the in-network storage 329 access protocol (IAP), which is a standard, P2P-application-agnostic 330 protocol for different P2P applications to access in-network storage. 331 IAP defines a set of commands that P2P application elements can issue 332 to in-network storage to store and retrieve data. IAP includes the 333 following functionalities: 335 (1) Data access provides read/write by users (e.g., P2P application 336 clients and content publishers) to the corresponding in-network 337 storage and between entities implementing the in-network storage; 339 (2) Authorization implements access control to resources provided by 340 in-network storage; 342 (3) Resource control allows users to implement application policies 343 for the corresponding in-network storage. 345 Note that DECADE is independent of current IETF work on P2P, e.g. 346 P2PSIP, ALTO, PPSP. For example, peers discovered by either RELOAD 347 or ALTO can all use DECADE to share data. 349 The Peer to Peer Streaming Protocol effort in the IETF is 350 investigating specification of signaling protocols (called PPSP 351 protocols) for multiple types of entities (e.g. intelligent 352 endpoints, caches, content distribution network nodes, and/or other 353 edge devices) to participate in P2P streaming systems in both fixed 354 and mobile Internet. As discussed in the PPSP problem statement 355 document [I-D.zhang-ppsp-problem-statement], one important PPSP use 356 case is the support of an in-network edge Cache for P2P Streaming. 357 However, this approach to providing in-network cache has different 358 applicability, different objectives and different implications for 359 the in-network cache operator. A DECADE service can be used for any 360 application transparently to the DECADE in-network storage operator: 361 it can be used for any P2P Streaming application (whether it supports 362 PPSP protocols or not), for any other P2P application, and for non 363 P2P applications that simply want to benefit from in-network storage. 364 So with DECADE the operator is providing a generic in-network storage 365 service that can be used by any application without application 366 involvement or awareness by the operator; in the PPSP cache use case, 367 the cache operator is participating in the specific P2P streaming 368 service. 370 DECADE and PPSP can both contribute independently, and (where 371 appropriate) simultaneously, to making content available closer to 372 peers. Here are a number of example scenarios: 374 A given network supports DECADE in-network storage, and its CDN 375 nodes do not participate as PPSP Peers for a given "stream" (e.g. 376 say because no CDN arrangement has been put in place between the 377 Content Provider and the considered network provider). In that 378 case, PPSP Peers will all be "off-net" but will be able to use 379 DECADE in-network storage to exchange chunks. 381 A given network does not support DECADE in-network storage, and 382 (some of) its CDN nodes participate as PPSP Peers for a given 383 "stream" (e.g. say because an arrangement has been put in place 384 between the Content Provider and the considered network provider). 385 In that case, the CDN nodes will participate as in-network PPSP 386 Peers. The off-net PPSP Peers (ie end users) will be able to get 387 chunks from the in-network CDN nodes (using PPSP protocols with 388 the CDN nodes). 390 A given network supports DECADE in-network storage, and (some of) 391 its CDN nodes participate as PPSP Peers for a given "stream" (e.g. 392 say because an arrangement has been put in place between the 393 Content Provider and the considered network provider). In that 394 case, the CDN nodes will participate as in-network PPSP Peers. 395 The off-net PPSP Peers (ie end users) will be able to get chunks 396 from the in-network CDN nodes (using PPSP protocols with the CDN 397 nodes) as well as be able to get chunks /share chunks using DECADE 398 in-network storage populated (using IAP protocol) by PPSP Peers 399 (both off-net end-users and in-network CDN Nodes). 401 While DECADE will focus on P2P applications, the solution is expected 402 to be applicable in other contexts with similar requirements. 404 4.1. Data access 406 P2P application clients use the protocol to read data from an in- 407 network storage, store data to an in-network storage, or remove data 408 from an in-network storage. The data could be of various types. 409 Existing protocols will be used wherever possible and appropriate to 410 support DECADE's requirements. In particular, data storage, 411 retrieval, and management may be provided by an existing IETF 412 protocols. The WG will not limit itself to a single data transport 413 protocol since different protocols may have varying implementation 414 costs and performance tradeoffs. However, to keep interoperability 415 manageable, a small number of specific, targeted, data transport 416 protocols will be identified and used. If a protocol is found to be 417 suitable but does not fully meet the requirements, then the protocol 418 may need to be extended. The following considerations should be 419 taken into account. But it might be a trade-off when making 420 decision. 422 o The protocol(s) should support deployments with a very large 423 number of users without substantial increase to operational 424 complexity for the storage provider. 426 o The protocol(s) should be easy for applications to integrate 427 with when they want to use it for P2P applications (e.g. file- 428 sharing or streaming) or other content distribution applications. 430 4.2. Authorization 432 DECADE ensures that access to the in-network storage is subject to 433 authorization by the user owning the in-network storage service. The 434 authorization can take into account the user trying to access, the 435 content, the time period, etc. 437 4.3. Resource control 439 A user uses the protocol to manage the resources on in-network 440 storage that can be used by other peers, e.g., the bandwidth or 441 connections. The resource control policies could be based on 442 individual remote peers or a whole application. 444 5. Usage Scenarios 446 Usage scenarios are described from two perspectives. First, we 447 introduce high-level use cases showing how P2P applications may 448 utilize in-network storage. Second, we show how in more detail how 449 users exchange data using IAP. 451 5.1. BitTorrent 453 BitTorrent may be integrated with DECADE to be more network efficient 454 and reduce the bandwidth consumed on ISP networks. When a BitTorrent 455 client uploads a block to peers, the block traverses the last-mile 456 uplink once for each peer. With DECADE, however, the BitTorrent 457 client may upload the block to its in-network storage. Peers may 458 retrieve the block from the in-network storage, reducing the amount 459 of data on the last-mile uplink. 461 We now describe in more detail how BitTorrent can utilize DECADE. 462 For illustration, we assume that both the BitTorrent client (A) and 463 its peer (B) utilize in-network storage. When A requests a block, it 464 indicates that it would like the block stored in its in-network 465 storage and provides the necessary access control. Instead of 466 sending the 'piece' message with the desired block, peer B replies 467 with a 'redirect' message indicating that the content should be 468 retrieved from its own in-network storage and provides the necessary 469 access control. If the peer B had not previously stored the content 470 in its in-network storage, it uploads the block. A downloads the 471 block into its own in-network storage from B's in-network storage, 472 and finally A itself retrieves the block. 474 Note that this requires extensions to the BitTorrent protocol. While 475 there are multiple ways to do so, this example assumes the native 476 BitTorrent 'request' message is extended to carry additional 477 information and that a new 'redirect' message is added. Upload and 478 download to/from in-network storage uses the standard IAP protocol. 480 This example has illustrated how utilizing DECADE can increase 481 BitTorrent's network efficiency. First, notice that peer B does not 482 utilize any uplink bandwidth if the block was already present in its 483 in-network storage. Second, notice that the block is downloaded 484 directly into A's in-network storage. When A wishes to share the 485 block with another peer (say, peer C) that supports DECADE, it may 486 upload directly from its in-network storage, again avoiding usage of 487 the last-mile uplink. 489 This technique can be applied to other P2P applications as well. 490 Since P2P applications use a standard for communicating with in- 491 network storage, they no longer require in-network storage to 492 explicitly support their protocol. P2P applications retain the 493 ability to explicitly manage which content is placed in in-network 494 storage, as well as access and resource control polices. 496 5.2. Content Publisher 498 Content Publishers may also utilize in-network storage. For example, 499 consider a P2P live streaming application. A Content Publisher 500 typically maintains a small number of sources, each of which 501 distributes blocks in the current play buffer to a set of the P2P 502 peers. 504 Consider a case where the Content Publisher owns an in-network 505 storage account within ISP A. If there are multiple P2P peers within 506 ISP A, the Content Publisher may utilize DECADE to distribute content 507 to the peers. 509 First, the Content Publisher stores a block in the in-network 510 storage, and then sends to each peer in ISP A the block's identifier 511 and necessary access control. Second, each peer may then download 512 from the Content Publisher's in-network storage. 514 In this example, the block is distributed in a more network efficient 515 way (the content only traverses the ISP's interdomain link once), 516 while the Content Publisher retains explicit control over access to 517 the content placed in its own storage. The Content Publisher can 518 remove content from its in-network storage when it is stale or needs 519 to be replaced, and grant access and resources to only the desired 520 peers. 522 Note that Content Publishers and individual peers can each use in- 523 network storage. For example, after downloading content from the 524 Content Publisher's in-network storage, peers may each utilize their 525 own in-networks storage similar to the usage scenario in Section 5.1. 526 This can have the benefit of increased network efficiency, while 527 Content Publishers and peers still retain control over content placed 528 in their own in-network storage. 530 5.3. Data Transfer Scenarios 532 The previous usage scenarios have utilized the ability for peers to 533 transfer data by storing and retrieving from in-network storage. 534 This section describes in further detail an example solution of how 535 DECADE can provide this capability. 537 In this section, we consider the case of a user B (the receiver) 538 requesting data from user A (the sender). We use Sa to denote User 539 A's storage account, and Sb to denote User B's storage account. Each 540 user independently decides if its in-network storage account is used, 541 so there are four cases. 543 When a user indicates that it wishes to use its in-network storage, 544 it provides an access control token the other user. The token is 545 sent using the application's protocol. To simplify the illustration, 546 we omit details of the access control from the detailed scenarios 547 below. 549 5.3.1. Both Sender and Receiver Accounts are Used 551 This scenario is illustrated in Figure 2. B first requests an object 552 from A using the application protocol indicating it wishes the object 553 to be stored in Sb. A responds using the application protocol 554 indicating that B should download the object from Sa. B sends a IAP 555 request to Sb indicating that the object should be downloaded from 556 Sa. Sb uses IAP to download from Sa, and finally, B downloads the 557 object from Sb (also using IAP). 559 +-------+ 4 IAP Get +-------+ 560 | Sa | <----------+ Sb | 561 +-------+ *********>+-------+ 562 5 data transfer ^ * 563 3 IAP Get \ * 6 data transfer 564 1 App request \ \ / 565 +-------+<-------------------+-------+ 566 |User A | |User B | 567 +-------+------------------->+-------+ 568 2 App response 570 Figure 2: Usage Scenario 1 (Sender and receiver Accounts used) 572 5.3.2. Only Sender's Storage Account is Used 574 This scenario is illustrated in Figure 3. B requests an object from 575 A using the application protocol. A responds using the application 576 protocol indicating that B should download the object from Sa. 577 Finally, B sends a IAP request to Sa to download the object. 579 +-------+ 580 | Sa | 581 +-------+ 582 ^ * 583 3 IAP Get \ * 4 data transfer 584 1 App request \ \/ 585 +-------+<-------------------+-------+ 586 |User A | |User B | 587 +-------+------------------->+-------+ 588 2 App response 590 Firgure 3: Usage Scenario 2 (Sender account used) 592 5.3.3. Only Receiver's Storage Account is Used 594 This scenario is illustrated in Figure 4. B requests an object from 595 A using the application protocol indicating that it wishes the object 596 to be stored in Sb. A stores the object in Sb (using IAP), and 597 responds to B (using the application protocol) that it should 598 download from Sb. B uses IAP to download the object from Sb. 599 +---------+ 600 > | Sb | 601 3. / +---------+ 602 IAP Store / ^ * 603 / 3.IAP Get \ * 4 data transfer 604 / 1.App request \ \/ 605 +-------+<-------------------+-------+ 606 |User A | |User B | 607 +-------+------------------->+-------+ 608 2.App response 610 Figure 4: Usage Scenario 3 (Receiver account used) 612 5.3.4. No Storage Accounts are Used 614 This scenario is illustrated in Figure 5. In this scenario, the 615 application protocol is used directly to send data. This scenario 616 applies with one of the peers does not support IAP, or neither of the 617 peers are using in-network storage. 619 1.App request 620 +-------+<-------------------+-------+ 621 |User A | ... ... ... |User B | 622 +-------+*******************>+-------+ 623 2.data transfer 625 Figure 5: Usage Scenario 4 ( No storage accounts used) 627 6. Security Considerations 629 There are multiple security considerations. We focus on two in this 630 section. 632 6.1. Denial of Service attack 634 Without access control or resource control, an attacker can try to 635 consume a large portion of the in-network storage, or exhaust the 636 connections of the in-network storage to commit a Denial of Service 637 (DoS) attack. Thus, access control and resource control mechanisms 638 are mandatory. A resource control mechanism should be used to allow 639 a user to allocate the resource in its in-network storage account to 640 be utilized by other clients. 642 6.2. Copyright and Legal issues 644 Copyright and other laws may prevent the distribution of certain 645 content in various localities. While in-network storage operators 646 may adopt system-wide ingress or egress filters to implement 647 necessary policies for storing or retrieving content, the 648 specification and implementation of such policies (e.g., filtering 649 and DRM) is outside of the scope of this working group. 651 7. IANA Considerations 653 There is no IANA consideration with this document. 655 8. Acknowledgments 657 We would like to thank the following people for contributing to this 658 document: 660 David Bryan 662 Francois Le Faucheur 663 Hongqiang Law. 665 Kar Ann Chew 667 Richard Woundy 669 Roni Even 671 Yunfei Zhang 673 Yu-shun Wang 675 Yingjie Gu 677 9. References 679 9.1. Normative References 681 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 682 Requirement Levels", BCP 14, RFC 2119, March 1997. 684 9.2. Informative References 686 [ipoque.com] 687 "http://www.ipoque.com/resources/internet-studies/ 688 internet-study-2008_2009". 690 [I-D.ietf-alto-problem-statement] 691 Seedorf, J. and E. Burger, "Application-Layer Traffic 692 Optimization (ALTO) Problem Statement", 693 draft-ietf-alto-problem-statement-04 (work in progress), 694 September 2009. 696 [I-D.weaver-alto-edge-caches] 697 Weaver, N., "Peer to Peer Localization Services and Edge 698 Caches", draft-weaver-alto-edge-caches-00 (work in 699 progress), March 2009. 701 [I-D.zhang-ppsp-problem-statement] 702 Zhang, Y., Zong, N., Camarillo, G., Seng, J., and Y. Yang, 703 "Problem Statement of P2P Streaming Protocol (PPSP)", 704 draft-zhang-ppsp-problem-statement-06 (work in progress), 705 July 2010. 707 [RFC3720] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M., 708 and E. Zeidner, "Internet Small Computer Systems Interface 709 (iSCSI)", RFC 3720, April 2004. 711 [RFC5661] Shepler, S., Eisler, M., and D. Noveck, "Network File 712 System (NFS) Version 4 Minor Version 1 Protocol", 713 RFC 5661, January 2010. 715 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 716 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 717 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 719 [DCIA] http://www.dcia.info, "Distributed Computing Industry 720 Association". 722 [ipoque.P2P_survey.] 723 "Emerging Technologies Conference at MIT", Sept. 2007. 725 [P2P_file_sharing] 726 Parker, A., "The true picture of peer-to-peer 727 filesharing", July 2004. 729 [ICNP] Wu, H., "Challenges and opportunities of Internet 730 developments in China, ICNP 2007 Keynote", Oct. 2007. 732 Authors' Addresses 734 Haibin Song 735 Huawei 736 Baixia Road No. 91 737 Nanjing, Jiangsu Province 210001 738 P.R.China 740 Phone: +86-25-56622975 741 Email: melodysong@huawei.com 743 Ning Zong 744 Huawei 745 Baixia Road No. 91 746 Nanjing, Jiangsu Province 210001 747 P.R.China 749 Phone: +86-25-56622975 750 Email: zongning@huawei.com 751 Y. Richard Yang 752 Yale University 754 Email: yry@cs.yale.edu 756 Richard Alimi 757 Yale University 759 Email: richard.alimi@yale.edu