idnits 2.17.1 draft-gu-decade-reqs-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: Depending on the object size (e.g., chunk size) used by a P2P application, the application may need to send data to the DECADE server in multiple packets. To keep implementation simple, the DECADE must at least support the ability to write the data sequentially in the order received. Implementations MAY allow application to write data in an object out-of-order (but MAY NOT overwrite ranges of the object that have already been stored). -- The document date (July 12, 2010) is 5035 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-02) exists of draft-song-decade-problem-statement-00 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Gu 3 Internet-Draft Huawei 4 Intended status: Informational D. Bryan 5 Expires: January 13, 2011 Cogent Force, LLC 6 Y. Yang 7 R. Alimi 8 Yale University 9 July 12, 2010 11 DECADE Requirements 12 draft-gu-decade-reqs-05 14 Abstract 16 The target of DECoupled Application Data Enroute (DECADE) is to 17 provide an open and standard in-network storage system for 18 applications, primarily P2P applications, to store, retrieve and 19 manage their data. This draft enumerates and explains requirements, 20 not only for store and retrieve, but also for data management, access 21 control and resource control, that should be considered during the 22 design and implementation of a DECADE system. These are requirements 23 on the entire system, some of the requirements may eventually be 24 implemented by an existing protocol with/without some extensions 25 (e.g. the data transport level), but a user of DECADE as a complete 26 architecture would be guaranteed such functionality. 28 Status of this Memo 30 This Internet-Draft is submitted to IETF in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF), its areas, and its working groups. Note that 35 other groups may also distribute working documents as Internet- 36 Drafts. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 The list of current Internet-Drafts can be accessed at 44 http://www.ietf.org/ietf/1id-abstracts.txt. 46 The list of Internet-Draft Shadow Directories can be accessed at 47 http://www.ietf.org/shadow.html. 49 This Internet-Draft will expire on January 13, 2011. 51 Copyright Notice 53 Copyright (c) 2010 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 2. Terminology and Concepts . . . . . . . . . . . . . . . . . . . 5 70 3. General Principles . . . . . . . . . . . . . . . . . . . . . . 6 71 3.1. Storage Management . . . . . . . . . . . . . . . . . . . . 6 72 3.2. Low-latency access . . . . . . . . . . . . . . . . . . . . 6 73 3.3. Efficient Transfer . . . . . . . . . . . . . . . . . . . . 6 74 3.4. Low equipment and management cost . . . . . . . . . . . . 7 75 3.5. Application-independent API . . . . . . . . . . . . . . . 7 76 3.6. Resource Control . . . . . . . . . . . . . . . . . . . . . 7 77 3.7. Data Object Size . . . . . . . . . . . . . . . . . . . . . 8 78 4. Data Access . . . . . . . . . . . . . . . . . . . . . . . . . 8 79 4.1. Reading/Writing Own Storage . . . . . . . . . . . . . . . 8 80 4.2. Access by Other Users . . . . . . . . . . . . . . . . . . 9 81 4.3. Communication among In-network Storage Elements . . . . . 10 82 5. Data Management . . . . . . . . . . . . . . . . . . . . . . . 10 83 5.1. Agnostic of reliability . . . . . . . . . . . . . . . . . 10 84 5.2. Explicit Deletion of Stored Data . . . . . . . . . . . . . 10 85 5.3. No ability to update . . . . . . . . . . . . . . . . . . . 11 86 5.4. Multiple writing . . . . . . . . . . . . . . . . . . . . . 11 87 5.5. Multiple reading . . . . . . . . . . . . . . . . . . . . . 11 88 5.6. Reading before completely writen . . . . . . . . . . . . . 11 89 5.7. Writing model . . . . . . . . . . . . . . . . . . . . . . 12 90 5.8. Time-to-live for Stored Data . . . . . . . . . . . . . . . 12 91 5.9. Storage Status . . . . . . . . . . . . . . . . . . . . . . 13 92 6. Resource Control . . . . . . . . . . . . . . . . . . . . . . . 13 93 6.1. Multiple Applications . . . . . . . . . . . . . . . . . . 13 94 6.2. Per-Peer, Per-Data Control . . . . . . . . . . . . . . . . 14 95 6.3. Server Involvement . . . . . . . . . . . . . . . . . . . . 14 96 7. Authorization . . . . . . . . . . . . . . . . . . . . . . . . 15 97 7.1. Per-Peer, Per-Data Read Access . . . . . . . . . . . . . . 15 98 7.2. Per-User Write Access . . . . . . . . . . . . . . . . . . 15 99 7.3. Authorization Checks . . . . . . . . . . . . . . . . . . . 15 100 7.4. Server Involvement . . . . . . . . . . . . . . . . . . . . 16 101 8. Data Availability . . . . . . . . . . . . . . . . . . . . . . 16 102 8.1. Offline Usage . . . . . . . . . . . . . . . . . . . . . . 16 103 9. Error Conditions . . . . . . . . . . . . . . . . . . . . . . . 16 104 9.1. Insufficient Resources . . . . . . . . . . . . . . . . . . 16 105 9.2. Unavailable and Deleted Data . . . . . . . . . . . . . . . 17 106 9.3. Overload Conditions . . . . . . . . . . . . . . . . . . . 17 107 10. Protocol Applicability . . . . . . . . . . . . . . . . . . . . 17 108 10.1. NATs and Firewalls . . . . . . . . . . . . . . . . . . . . 18 109 10.2. Connections to Clients . . . . . . . . . . . . . . . . . . 18 110 10.3. Cross-platform Access . . . . . . . . . . . . . . . . . . 18 111 11. Security Considerations . . . . . . . . . . . . . . . . . . . 19 112 12. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 19 113 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 114 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 115 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 116 15.1. Normative References . . . . . . . . . . . . . . . . . . . 20 117 15.2. Informative References . . . . . . . . . . . . . . . . . . 20 118 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 120 1. Introduction 122 The target of DECoupled Application Data Enroute (DECADE) is to 123 provide an open and standard in-network storage system for 124 applications, primarily P2P applications, to store, retrieve and 125 manage their data. Instead of transferring data directly from 126 source-owner peer to requesting peer, source-owner peer can store and 127 manage its content on its in-network storage. The requesting peer 128 can get the address of the in-network storage pertaining to the 129 source-owner peer and retrieve data form the storage. This draft 130 enumerates and explains specific requirements that should be 131 considered during the design and implementation of a DECADE 132 system.Though more effort may be made to analyze the suitability to 133 other applications with the same data operation requirements, we 134 still consider P2P applications as the only target when we composing 135 this draft, before any decision has been made. 137 This document enumerates the requirements to enable target 138 applications to utilize in-network storage. In this context, using 139 storage resources includes basic capability such as storing and 140 retrieving data, and managing data, but also (1) controlling access 141 by peers with which it is sharing data and (2) controlling the 142 resources used by remote peers to access that data. 144 This document also explains the rationale behind requirements that 145 should be considered in the specification of a protocol for DECADE. 146 More details about DECADE can be found in the problem statement 147 [I-D.song-decade-problem-statement]. 149 This document will be updated to track revisions to the problem 150 statement. 152 2. Terminology and Concepts 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 156 document are to be interpreted as described in [RFC2119]. 158 This document uses terms defined in 159 [I-D.song-decade-problem-statement]. In particular, IAP refers to 160 the In-network storage Access Protocol, which is the protocol used to 161 communicate between a DECADE client and DECADE server (in-network 162 storage) for access control and resource control. 164 3. General Principles 166 A number of general principles are identified in this section. These 167 general principles are important in achieving the goal of DECADE to 168 be useful in many P2P applications. 170 3.1. Storage Management 172 3.1.1. Requirement 174 DECADE MUST support the ability for a user to own and manage storage 175 space at in-network storage element. The in-network storage element 176 may be a logical element, and the physical resources used to support 177 that element are owned and managed by the provider. 179 3.1.2. Rationale 181 A primary departure from an existing form of in-network storage, P2P 182 caching, is the ability for applications to manage the data stored. 183 This allows applications to persist data in the network without fear 184 that it may be deleted (e.g., pushed out of the cache) by other 185 users. And it also allows applications to implement policies to meet 186 their own requirements (e.g., BitTorrent vs. eMule vs. PPLive) 188 3.2. Low-latency access 190 3.2.1. Requirements 192 DECADE MUST provides low-latency access for application clients. 194 3.2.2. Rationale 196 Some applications may have requirements on delivery time (e.g., live 197 streaming). Ueser experience may be unsatifactory if DECADE 198 introduces much larger latency than applications without in-network 199 storage between peers. 201 3.3. Efficient Transfer 203 3.3.1. Requirements 205 DECADE MUST allow a user's in-network storage to directly fetch from 206 other user's in-network storage 208 3.3.2. Rationale 210 For example, a requesting peer gets the address of the storage 211 pertaining to the source-owner peer and then tells its own in-network 212 storage to fetch the content from the source-owner's in-network 213 storage. This helps to avoid extra transfers across ISP network 214 links where possible. 216 3.4. Low equipment and management cost 218 3.4.1. Requirements 220 DECADE SHOULD should have low equipment and management cost per user. 222 3.4.2. Rationale 224 Storage should be offered to users at minimal cost (Note that storage 225 providers may implement higher reliability guarantees if desired). 226 For example, storages could be "out-of-path" and built with commodity 227 hardware ("in-path" components must be carrier grade, meaning higher 228 equipment and management costs). Additionally, P2P applications may 229 revert to native protocols for data transport. 231 3.5. Application-independent API 233 3.5.1. Requirements 235 DECADE MUST provide simple, application-independent API for P2P 236 applications to access in-network storage. 238 3.5.2. Rationale 240 Since P2P application APIs don't support in-network storage 241 management, new appliction-independent API must be introduced. The 242 API should be simple, or it is hard to adopt. Besides, API must 243 abide by the requirements list above. 245 3.6. Resource Control 247 3.6.1. Requirement 249 DECADE MUST provide the ability for a user to define resource control 250 policies for managing the resources consumed by requesting users when 251 reading from / writing to the storage. A DECADE client MUST be able 252 to control parameters for at least the following types of resources: 254 o Bandwidth (relative weight) 256 o Storage space 258 o Network connections 260 3.6.2. Rationale 262 Recent developments in P2P systems have rely on resource-control to 263 achieve certain application-level goals, such as improving incentives 264 [LLSB08] and forming distribution topologies [PPLive]. It is 265 important that DECADE provides basic support for applications to meet 266 such requirements. Thus, DECADE supports more than the ability read 267 and write data. In particular, DECADE also supports the ability to 268 control resources used by remote peers while accessing data in in- 269 network storage. 271 There can multiple options when controlling bandwidth used by remote 272 peers. We indicate that a relative weight can be used to share 273 bandwidth amongst multiple external peers. Other possibilities (not 274 exclusive of using a relative weight) may be to also specify a 275 maximum bandwidth, or indicating an order in which requests should be 276 served (as is done in eMule). However, care should be taken to not 277 require complex implementation by the server. 279 3.7. Data Object Size 281 3.7.1. Requirement 283 DECADE MUST allow for efficient data transfer of small objects (e.g., 284 16KB) between a DECADE client and in-network storage with only 285 minimal additional latency required by the protocol. 287 3.7.2. Rationale 289 Though P2P applications are frequently used to share large amounts of 290 data (e.g., continuous streams or large files), the data itself is 291 typically subdivided into smaller chunks that are transferred between 292 peers. Additionally, the small chunks may have requirements on 293 delivery time (e.g., in a live-streaming application). DECADE must 294 enable data to be efficiently transferred amongst peers at this 295 granularity. 297 Note that DECADE should allow for efficient data transfer for larger 298 data objects as well. 300 4. Data Access 302 4.1. Reading/Writing Own Storage 303 4.1.1. Requirement 305 DECADE MUST support the ability for a DECADE client to read data from 306 and write data to its own in-network storage. 308 4.1.2. Rationale 310 Two basic capabilities for any storage system are reading and writing 311 data. A DECADE client can read data from and write data to in- 312 network storage space that it owns. 314 4.1.3. Requirement 316 DECADE MUST support the ability for a DECADE client to negotiate with 317 its In-network storage about which protocol it can use to read data 318 from and write data to its In-network storage. 320 4.1.4. Rationale 322 Since typical data transport protocols (e.g., NFS and WebDAV) already 323 provide read and write operations for network storage, it is not 324 necessary for DECADE to define such operations in a new protocol. 325 However, because of the particular application requirements and 326 deployment considerations, different applications may support 327 different protocols. Thus, a DECADE client must be able to select an 328 appropriate protocol also supported by the in-network storage. 330 4.2. Access by Other Users 332 4.2.1. Requirement 334 DECADE MUST support the ability for a user to apply access control 335 policies to users other than itself for its storage. The users with 336 whom access is being shared can be under a different administrative 337 domain than the user who owns the in-network storage. The authorized 338 users may read from or write to the user 's storage. 340 4.2.2. Rationale 342 Peers in a P2P application may be located across multiple ISPs under 343 multiple administrative domains. Thus, to be useful by P2P 344 applications, DECADE allows a user to specify access control policies 345 for users that may or may not be known to the user's storage 346 provider. 348 4.3. Communication among In-network Storage Elements 350 4.3.1. Requirement 352 DECADE SHOULD support the ability for two in-network storage elements 353 in different administrative domains to store and/or retrieve data 354 directly between each other. If such a protocol is supported, this 355 MAY be the same (or a subset or extension of) as the IAP protocol. 357 4.3.2. Rationale 359 Allowing server-to-server communication can reduce latency in some 360 common scenarios. Consider a scenario when a DECADE client is 361 downloading data into its own storage from another client's in- 362 network storage. One possibility is for the client to first download 363 the data itself, and then upload it to its own storage. However, 364 this causes unnecessary latency and network traffic. Allowing the 365 data to be downloaded from the remote in-network storage into the 366 client's own in-network storage can alleviate both. 368 5. Data Management 370 5.1. Agnostic of reliability 372 5.1.1. Requirement 374 DECADE SHOULD remain agnostic of reliability/fault-tolerance level 375 offered by storage provider. 377 5.1.2. Rationale 379 Providers of a DECADE service may wish to offer varying levels of 380 service for different applications/users. However, a single 381 compliant DECADE client should be able to use multiple DECADE 382 services with differing levels of service. 384 5.2. Explicit Deletion of Stored Data 386 5.2.1. Requirement 388 DECADE MUST support the ability for a DECADE client to explicitly 389 delete data from its own in-network storage. 391 5.2.2. Rationale 393 A DECADE client may continually be writing data to its in-network 394 storage. Since there may be a limit (e.g., imposed by the storage 395 provider) to how much total storage can be used, some data may need 396 to be removed to make room for additional data. A DECADE client 397 should be able to explicitly remove particular data. This may be 398 implemented using existing protocols. 400 5.3. No ability to update 402 5.3.1. Requirement 404 DECADE SHOULD NOT provide ability to update existing objects. That 405 is, objects are immutable once they are stored. 407 5.3.2. Rationale 409 Reasonable consistency models for updating existing objects would 410 significantly complicate implementation (especially if implementation 411 chooses to replicate data across multiple servers). If a user needs 412 to update a resource, it can store a new resource and then distribute 413 the new resource instead of the old one. 415 5.4. Multiple writing 417 5.4.1. Requirement 419 DECADE MUST NOT allow multiple writers for the same object. 420 Implementations raise an error to one of the writers. 422 5.4.2. Rationale 424 This avoids data corruption in a simple way while remaining 425 efficient. 427 5.5. Multiple reading 429 5.5.1. Requirement 431 DECADE MUST allow for multiple readers for an object. 433 5.5.2. Rationale 435 One characteristic of P2P applications is the ablility to upload an 436 object to multiple peers. Thus, it is natural for DECADE to allow 437 multiple readers to access the content concurrently. 439 5.6. Reading before completely writen 440 5.6.1. Requirement 442 DECADE MAY allow readers to read from objects before they have been 443 completely written. 445 5.6.2. Rationale 447 Some P2P systems (in particular, streaming) can be sensitive to 448 latency. A technique to reduce latency is to remove store-and- 449 forward delays for data objects (e.g., make the object available 450 before it is completely stored). Appropriate handling for error 451 conditions (e.g., a disappearing writer) needs to be specified. 453 5.7. Writing model 455 5.7.1. Requirement 457 DECADE MUST provide at least a writing model (while storing an 458 object) that appends data to data already stored. 460 5.7.2. Rationale 462 Depending on the object size (e.g., chunk size) used by a P2P 463 application, the application may need to send data to the DECADE 464 server in multiple packets. To keep implementation simple, the 465 DECADE must at least support the ability to write the data 466 sequentially in the order received. Implementations MAY allow 467 application to write data in an object out-of-order (but MAY NOT 468 overwrite ranges of the object that have already been stored). 470 5.8. Time-to-live for Stored Data 472 5.8.1. Requirement 474 DECADE MUST support the ability for a DECADE client to indicate a 475 time-to-live value (or expiration time) indicating a length of time 476 until particular data is deleted by the in-network storage element. 478 5.8.2. Rationale 480 Some data stored by a DECADE client may be usable only within a 481 certain window of time, such as in live-streaming P2P applications. 482 Providing a time-to-live value for stored data (e.g., at the time it 483 is stored) can reduce management overhead by avoiding many 'delete' 484 commands sent to in-network storage. 486 5.9. Storage Status 488 5.9.1. Requirement 490 A DECADE client MUST be able to retrieve current resource usage 491 (including list of stored data) and resource quotas on its in-network 492 storage. 494 5.9.2. Rationale 496 The resources used by a client are not directly-attached (e.g., disk, 497 network interface, etc). Thus, the client cannot locally determine 498 how such resources are being used. Before storing and retrieving 499 data, a client should be able to determine which data is available 500 (e.g., after an application restart). Additionally, a client should 501 be able to determine resource availability (see Section 3.6) to 502 better allocate them to remote peers. 504 6. Resource Control 506 6.1. Multiple Applications 508 6.1.1. Requirement 510 DECADE SHOULD support the ability for users to define resource 511 sharing policies for multiple applications being run/managed by the 512 user. 514 6.1.2. Rationale 516 A user may own in-network storage and share the in-network storage 517 resources amongst multiple applications. For example, the user may 518 run a video-on-demand application and a live-streaming (or even two 519 different live-streaming applications) application which both make 520 use of the user's in-network storage. The applications may be 521 running on different machines and may not directly communicate. 522 Thus, DECADE should enable the user to determine resource sharing 523 policies between the applications. 525 One possibility is for a user to indicate the particular resource 526 sharing policies between applications out-of-band (not using a 527 standard protocol), but this requirement may manifest itself in 528 passing values over IAP to identify individual applications. Such 529 identifiers can be either user-generated or server-generated and do 530 not need to be registered by IANA. 532 6.2. Per-Peer, Per-Data Control 534 6.2.1. Requirement 536 A DECADE client MUST be able to assign resource quotas to individual 537 peers for reading from and writing particular data to its in-network 538 storage within a particular range of time. 540 6.2.2. Rationale 542 P2P applications can rely on control of resources on a per-peer or 543 per-data basis. For example, application policy may indicate that 544 certain peers have a higher bandwidth share for receiving data. 545 Additionally, certain data (e.g., chunks) may be distributed with a 546 higher priority. As another example, when allowing a remote peer to 547 write data to a user's in-network storage, the remote peer may be 548 restricted to write only a certain amount of data. Since the client 549 may need to manage multiple peers accessing its data, it should be 550 able to indicate the time over which the granted resources are 551 usable. For example, an expiration time for the access could be 552 indicated to the server after which no resources are granted (e.g., 553 indicate error as access denied). 555 6.3. Server Involvement 557 6.3.1. Requirement 559 A DECADE client MUST be able to indicate, without contacting the 560 server itself, resource control policies for peers' requests. 562 6.3.2. Rationale 564 One important consideration for in-network storage elements is 565 scalability, since a single storage element may be used to support 566 many users. Many P2P applications use small chunk sizes and frequent 567 data exchanges. If such an application employed resource control and 568 contacted the in-network storage element for each data exchange, this 569 could present a scalability challenge for the server as well as 570 additional latency for clients. 572 An alternative is to let requesting users get the resource control 573 policies and userrs can then present the policy to the storage 574 directly. This can result in reduced messaging handled by the in- 575 network storage. 577 7. Authorization 579 7.1. Per-Peer, Per-Data Read Access 581 7.1.1. Requirement 583 A DECADE Client MUST be able to authorize individual peers to read 584 particular data stored on its in-network storage. 586 7.1.2. Rationale 588 A P2P application can control certain application-level policies by 589 sending particular data (e.g., chunks) to certain peers. It is 590 important that peers not be able to circumvent such decisions by 591 arbitrarily reading any currently-stored data in in-network storage. 593 7.2. Per-User Write Access 595 7.2.1. Requirement 597 A DECADE Client MUST be able to authorize individual peers to store 598 data into its in-network storage. 600 7.2.2. Rationale 602 The space managed by a user in in-network storage can be a limited 603 resource. At the same time, it can be useful to allow remote peers 604 to write data directly to a user's in-network storage. Thus, a 605 DECADE client should be able to grant only certain peers this 606 privilege. 608 Note that it is not (currently) a requirement to check that a peer 609 stores a particular set of data (e.g., the check that a remote peer 610 writes the expected chunk of a file). Enforcing this as a 611 requirement would require a client to know which data is expected 612 (e.g., the full chunk itself or a hash of the chunk) which may not be 613 available in all applications. Checking for a particular hash could 614 be considered as a requirement in the future that could optionally be 615 employed by applications. 617 7.3. Authorization Checks 619 7.3.1. Requirement 621 In-network storage MUST check the authorization of a client before it 622 executes a supplied request. The in-network storage MAY use 623 optimizations to avoid such authorization checks as long as the 624 enforced permissions are the the same. 626 7.3.2. Rationale 628 Authorization granted by a DECADE client are meaningless unless 629 unauthorized requests are denied access. Thus, the in-network 630 storage element must verify the authorization of a particular request 631 before it is executed. 633 7.4. Server Involvement 635 7.4.1. Requirement 637 A DECADE client MUST be able to indicate, without contacting the 638 server itself, access control policies for peers' requests. 640 7.4.2. Rationale 642 See discussion in Section 6.3.2. 644 8. Data Availability 646 8.1. Offline Usage 648 8.1.1. Requirement 650 DECADE MAY support the ability for a user to provide authorized 651 access to its in-network storage even if the user has no DECADE 652 applications actively running or connected to the network. 654 8.1.2. Rationale 656 If an application desires, it can authorize peers to access its 657 storage even after the application exits or network connectivity is 658 lost. An example use case is mobile scenarios, where a client can 659 lose and regain network connectivity very often. 661 9. Error Conditions 663 9.1. Insufficient Resources 665 9.1.1. Requirement 667 DECADE MUST support an error condition indicating to a DECADE client 668 that resources (e.g., storage space) were not available to service a 669 request (e.g., storage quota exceeded when attempting to store data). 671 9.1.2. Rationale 673 The currently-used resource levels within the in-network storage are 674 not locally-discoverable, since the resources (disk, network 675 interfaces, etc) are not directly attached. In order to allocate 676 resources appropriately amongst peers, a client must be able to 677 determine when resource limits have been reached. The client can 678 then respond by explicitly freeing necessary resources or waiting for 679 such resources to be freed. 681 9.2. Unavailable and Deleted Data 683 9.2.1. Requirement 685 DECADE MUST support error conditions indicating that (1) data was 686 rejected from being stored, (2) deleted, or (3) marked unavailable by 687 a storage provider. 689 9.2.2. Rationale 691 Storage providers may require the ability to (1) avoid storing, (2) 692 delete, or (3) quarantine certain data that has been identified as 693 illegal (or otherwise prohibited). DECADE does not indicate how such 694 data is identified, but applications using DECADE should not break if 695 a storage provider is obligated to enforce such policies. 696 Appropriate error conditions should be indicated to applications. 698 9.3. Overload Conditions 700 9.3.1. Requirement 702 In-network storage, which is operating close to its capacity limit 703 (e.g., too busy servicing other requests), MUST be able to reject 704 requests. 706 9.3.2. Rationale 708 When in-network storage is operating at a limit where it may not be 709 able to process additional requests, it should not be required to 710 generate responses to such additional requests. Forcing the in- 711 network storage to do so can impair its ability to service existing 712 requests. 714 10. Protocol Applicability 715 10.1. NATs and Firewalls 717 10.1.1. Requirement 719 DECADE SHOULD be usable across firewalls and NATs without requiring 720 additional network support (e.g., Application-level Gateways). 722 10.1.2. Rationale 724 Firewalls and NATs are widely used in the Internet today, both in ISP 725 networks and within households. Deployment of DECADE must not 726 require modifications to such devices (beyond, perhaps, 727 reconfiguration). 729 10.2. Connections to Clients 731 10.2.1. Requirement 733 DECADE SHOULD NOT require that network connections be made to DECADE 734 clients (e.g., from a server to a DECADE client or from a DECADE 735 client to another DECADE client). 737 10.2.2. Rationale 739 Many household networks and operating systems have firewalls and NATs 740 configured by default. To ease deployment by avoiding configuration 741 changes and help mitigate security risks, DECADE should not require 742 clients to listen for any incoming network connections (beyond what 743 is required by any other already-deployed application). 745 10.3. Cross-platform Access 747 10.3.1. Requirement 749 If DECADE supports the ability to store metadata associated with data 750 objects, the DECADE protocol(s) MUST transmit any metadata using an 751 operating system-independent and architecture-independent format. 753 10.3.2. Rationale 755 If DECADE supports the possibilty for storing metadata (e.g., a 756 description, uploaded date, or object size), a possible use for the 757 metadata is to help a DECADE client locate a desired data object. 758 Data objects may be stored by DECADE clients running on various 759 platforms. To enable metadata to be readable regardles of its source 760 it must be transmitted to and from the DECADE server in a standard 761 format. 763 11. Security Considerations 765 Authorization for access to in-network storage is an important part 766 of the requirements listed in this document. Authorization for 767 access to storage resources and the data itself is important for 768 users to be able to manage and limit distribution of content. For 769 example, a user may only wish to share particular content with 770 certain peers. 772 If the authorization technique implemented in DECADE passes any 773 private information (e.g., user passwords) over the wire, it MUST be 774 passed in a secure way. 776 12. Discussion 778 Sometimes, several logical in-network storages could be deployed on 779 the same physical network device. In this case, in-network storages 780 on the same physical network device can communicate and transfer data 781 through internal communication messages. However in-network storages 782 deployed on different physical network devices SHOULD communicate 783 with in-network storage Access Protocol (IAP). 785 To provide fairness among users, the in-network storage provider 786 should assign resource (e.g., storage, bandwidth, connections) quota 787 for users. This can prevent a small number of clients from occupying 788 large amounts of resources on the in-network storage, while others 789 starve. 791 13. IANA Considerations 793 There is no IANA consideration with this document. 795 14. Acknowledgments 797 We would also like to thank Haibin Song for substantial contributions 798 to earlier versions of this document. We would also like to thank 799 Reinaldo Penno, Alexey Melnikov, Rich Woundy, Ning Zong, and Roni 800 Even for contributions and feedback. 802 15. References 803 15.1. Normative References 805 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 806 Requirement Levels", BCP 14, RFC 2119, March 1997. 808 15.2. Informative References 810 [I-D.song-decade-problem-statement] 811 Yongchao, S., Zong, N., Yang, Y., and R. Alimi, "DECoupled 812 Application Data Enroute (DECADE) Problem Statement", 813 draft-song-decade-problem-statement-00 (work in progress), 814 October 2009. 816 [LLSB08] Dave Levin, Katrina LaCurts, Neil Spring, Bobby 817 Bhattacharjee., "BitTorrent is an Auction: Analyzing and 818 Improving BitTorrent's Incentives", In SIGCOMM 2008. 820 [PPLive] "PPLive", http://www.pplive.com. 822 Authors' Addresses 824 Yingjie Gu 825 Huawei 826 Baixia Road No. 91 827 Nanjing, Jiangsu Province 210001 828 P.R.China 830 Phone: +86-25-84565868 831 Email: guyingjie@huawei.com 833 David A. Bryan 834 Cogent Force, LLC 836 Email: dbryan@ethernot.org 838 Yang Richard Yang 839 Yale University 841 Email: yry@cs.yale.edu 842 Richard Alimi 843 Yale University 845 Email: richard.alimi@yale.edu