idnits 2.17.1 draft-ietf-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 document date (October 31, 2011) is 4554 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-06) exists of draft-ietf-decade-problem-statement-03 == Outdated reference: A later version (-10) exists of draft-ietf-decade-arch-02 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DECADE Y. Gu 3 Internet-Draft Huawei 4 Intended status: Informational D. Bryan 5 Expires: May 3, 2012 Polycom, Inc. 6 Y. Yang 7 Yale University 8 R. Alimi 9 Google 10 October 31, 2011 12 DECADE Requirements 13 draft-ietf-decade-reqs-05 15 Abstract 17 The target of DECoupled Application Data Enroute (DECADE) is to 18 provide an open and standard in-network storage system for 19 applications, primarily P2P (peer-to-peer) applications, to store, 20 retrieve and manage their data. This draft enumerates and explains 21 requirements, not only for storage and retrieval, but also for data 22 management, access control and resource control, that should be 23 considered during the design and implementation of a DECADE system. 24 These are requirements on the entire system; some of the requirements 25 may eventually be implemented by an existing protocol with/without 26 some extensions (e.g., a protocol used to read and write data from 27 the storage system). The requirements in this document are intended 28 to ensure that the DECADE architecture includes all of the desired 29 functionality for intended applications. 31 Requirements Language 33 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 34 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 35 document are to be interpreted as described in [RFC2119]. 37 Status of this Memo 39 This Internet-Draft is submitted to IETF in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF), its areas, and its working groups. Note that 44 other groups may also distribute working documents as Internet- 45 Drafts. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 The list of current Internet-Drafts can be accessed at 53 http://www.ietf.org/ietf/1id-abstracts.txt. 55 The list of Internet-Draft Shadow Directories can be accessed at 56 http://www.ietf.org/shadow.html. 58 This Internet-Draft will expire on May 3, 2012. 60 Copyright Notice 62 Copyright (c) 2011 IETF Trust and the persons identified as the 63 document authors. All rights reserved. 65 This document is subject to BCP 78 and the IETF Trust's Legal 66 Provisions Relating to IETF Documents 67 (http://trustee.ietf.org/license-info) in effect on the date of 68 publication of this document. Please review these documents 69 carefully, as they describe your rights and restrictions with respect 70 to this document. Code Components extracted from this document must 71 include Simplified BSD License text as described in Section 4.e of 72 the Trust Legal Provisions and are provided without warranty as 73 described in the BSD License. 75 Table of Contents 77 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 78 2. Terminology and Concepts . . . . . . . . . . . . . . . . . . . 6 79 3. Requirements Structure . . . . . . . . . . . . . . . . . . . . 6 80 4. Protocol Requirements . . . . . . . . . . . . . . . . . . . . 7 81 4.1. Overall Protocol Requirements . . . . . . . . . . . . . . 7 82 4.1.1. Connectivity Concerns . . . . . . . . . . . . . . . . 7 83 4.1.1.1. NATs and Firewalls . . . . . . . . . . . . . . . . 7 84 4.1.1.2. Connections to Clients . . . . . . . . . . . . . . 7 85 4.1.2. Security . . . . . . . . . . . . . . . . . . . . . . . 8 86 4.1.2.1. Secure Transport . . . . . . . . . . . . . . . . . 8 87 4.1.3. Error and Failure Conditions . . . . . . . . . . . . . 8 88 4.1.3.1. Overload Condition . . . . . . . . . . . . . . . . 8 89 4.1.3.2. Insufficient Resources . . . . . . . . . . . . . . 8 90 4.1.3.3. Unavailable and Deleted Data . . . . . . . . . . . 9 91 4.1.3.4. Insufficient Permissions . . . . . . . . . . . . . 9 92 4.1.3.5. Redirection . . . . . . . . . . . . . . . . . . . 9 93 4.2. Transfer and Latency Requirements . . . . . . . . . . . . 9 94 4.2.1. Low-Latency Access . . . . . . . . . . . . . . . . . . 9 95 4.2.2. Data Object Size . . . . . . . . . . . . . . . . . . . 10 96 4.2.3. Communication among DECADE Servers . . . . . . . . . . 10 97 4.3. Data Access Requirements . . . . . . . . . . . . . . . . . 11 98 4.3.1. Reading/Writing Own Storage . . . . . . . . . . . . . 11 99 4.3.2. Access by Other Users . . . . . . . . . . . . . . . . 11 100 4.3.3. Negotiable Data Transport Protocol . . . . . . . . . . 11 101 4.3.4. Separation of Data and Control Policies . . . . . . . 12 102 4.4. Data Management Requirements . . . . . . . . . . . . . . . 12 103 4.4.1. Agnostic of reliability . . . . . . . . . . . . . . . 12 104 4.4.2. Data Object Attributes . . . . . . . . . . . . . . . . 12 105 4.4.3. Time-to-live for Written Data Objects . . . . . . . . 13 106 4.4.4. Offline Usage . . . . . . . . . . . . . . . . . . . . 13 107 4.5. Data Naming Requirements . . . . . . . . . . . . . . . . . 13 108 4.5.1. Unique Names . . . . . . . . . . . . . . . . . . . . . 13 109 4.6. Resource Control . . . . . . . . . . . . . . . . . . . . . 14 110 4.6.1. Multiple Applications . . . . . . . . . . . . . . . . 14 111 4.6.2. Per-Remote-Client, Per-Data Control . . . . . . . . . 14 112 4.6.3. Server Involvement . . . . . . . . . . . . . . . . . . 15 113 4.7. Authorization . . . . . . . . . . . . . . . . . . . . . . 15 114 4.7.1. Per-Remote-Client, Per-Data Read Access . . . . . . . 15 115 4.7.2. Per-User Write Access . . . . . . . . . . . . . . . . 15 116 4.7.3. Default Access Permissions . . . . . . . . . . . . . . 16 117 4.7.4. Authorization Checks . . . . . . . . . . . . . . . . . 16 118 4.7.5. Cryptographic Credentials . . . . . . . . . . . . . . 16 119 4.7.6. Server Involvement . . . . . . . . . . . . . . . . . . 16 120 4.7.7. Protocol Reuse . . . . . . . . . . . . . . . . . . . . 17 121 4.8. Non-Requirements . . . . . . . . . . . . . . . . . . . . . 17 122 4.8.1. Application-defined Properties and Metadata . . . . . 17 124 5. Storage Requirements . . . . . . . . . . . . . . . . . . . . . 17 125 5.1. Immutable Data . . . . . . . . . . . . . . . . . . . . . . 17 126 5.2. Explicit Deletion of Data . . . . . . . . . . . . . . . . 18 127 5.3. Multiple writing . . . . . . . . . . . . . . . . . . . . . 18 128 5.4. Multiple reading . . . . . . . . . . . . . . . . . . . . . 18 129 5.5. Reading before completely written . . . . . . . . . . . . 18 130 5.6. Hints concerning usage of written data . . . . . . . . . . 19 131 5.7. Writing model . . . . . . . . . . . . . . . . . . . . . . 19 132 5.8. Storage Status . . . . . . . . . . . . . . . . . . . . . . 19 133 6. Discovery Requirements . . . . . . . . . . . . . . . . . . . . 20 134 6.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 20 135 6.1.1. Locating DECADE Servers . . . . . . . . . . . . . . . 20 136 6.1.2. Support for Clients Behind NATs and Firewalls . . . . 20 137 6.1.3. Prefer Existing Protocols . . . . . . . . . . . . . . 20 138 7. Future Considerations . . . . . . . . . . . . . . . . . . . . 21 139 7.1. Fairness . . . . . . . . . . . . . . . . . . . . . . . . . 21 140 7.2. Removal of Duplicate Data Objects . . . . . . . . . . . . 21 141 7.3. Gaming of the Resource Control Mechanism . . . . . . . . . 21 142 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 143 8.1. Authentication and Authorization . . . . . . . . . . . . . 22 144 8.2. Encrypted Data . . . . . . . . . . . . . . . . . . . . . . 22 145 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 146 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 147 10.1. Normative References . . . . . . . . . . . . . . . . . . . 22 148 10.2. Informative References . . . . . . . . . . . . . . . . . . 22 149 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 23 150 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 152 1. Introduction 154 The object of DECoupled Application Data Enroute (DECADE) is to 155 provide an open and standard in-network storage system for content 156 distribution applications, where data is typically broken into one or 157 more chunks and then distributed. This may already include many 158 types of applications including P2P applications, IPTV (Internet 159 Protocol Television), and VoD (Video on Demand). (For a precise 160 definition of the applications targeted in DECADE, see the definition 161 for Target Application in Section 2.) Instead of always transferring 162 data directly from a source/owner client to a requesting client, the 163 source/owner client can write to and manage its content on its in- 164 network storage. The requesting client can get the address of the 165 in-network storage pertaining to the source/owner client and read 166 data from the storage. 168 This draft enumerates and explains the rationale behind SPECIFIC 169 requirements on the protocol design and on any data store 170 implementation that may be used to implement DECADE servers that 171 should be considered during the design and implementation of a DECADE 172 system. As such, it DOES NOT include general guiding principles. 173 General design considerations, explanation of the problem being 174 addressed, and enumeration of the types of applications to which 175 DECADE may be suited is not considered in this document. For general 176 information, please see the problem statement 177 [I-D.ietf-decade-problem-statement] and architecture 178 [I-D.ietf-decade-arch] drafts. 180 This document enumerates the requirements to enable target 181 applications to utilize in-network storage. In this context, using 182 storage resources includes not only basic capabilities such as 183 writing, reading, and managing data, but also controlling access for 184 particular remote clients with which it is sharing data. 185 Additionally, we also consider controlling the resources used by 186 remote clients when they access data as an integral part of utilizing 187 the network storage. 189 This document discusses requirements pertaining to DECADE 190 protocol(s). In certain deployments, several logical in-network 191 storage systems could be deployed (e.g., within the same 192 administrative domain). These in-network storage systems can 193 communicate and transfer data through internal or non-standard 194 communication messages that are outside of the scope of these 195 requirements, but they SHOULD use DECADE protocol(s) when 196 communicating with other DECADE-capable in-network storage systems. 198 2. Terminology and Concepts 200 This document uses terms defined in 201 [I-D.ietf-decade-problem-statement]. 203 This document also defines additional terminology: 205 Target Application: An application (typically installed at end-hosts) 206 with the ability to explicitly control usage of network and/or 207 storage resources to deliver content to a large number of users. 208 This includes scenarios where multiple applications or entities 209 cooperate, such as with P2P, CDN, and hybrid P2P/CDN architectures. 210 Such applications distribute large amounts of content (e.g., a large 211 file, or video stream) by dividing the content into smaller blocks 212 for more flexible distribution (e.g., over multiple application-level 213 paths). The distributed content is typically immutable (though it 214 may be deleted). We use the term Target Application to refer to the 215 type of applications that are explicitly (but not exclusively) 216 supported by DECADE. 218 3. Requirements Structure 220 The DECADE protocol is intended to sit between Target Applications 221 and a back-end storage system. DECADE does not intend to develop yet 222 another storage system, but rather to create a protocol that enables 223 Target Applications to make use of storage within the network, 224 leaving specific storage system considerations to the implementation 225 of the DECADE servers as much as possible. For this reason, we have 226 divided the requirements into two primary categories: 228 o Protocol Requirements: Protocol requirements for Target 229 Applications to make use of in-network storage within their own 230 data dissemination schemes. Development of these requirements is 231 guided by a study of data access, search and management 232 capabilities used by Target Applications. These requirements may 233 be met by a combination of existing protocols and new protocols. 235 o Storage Requirements: Functional requirements necessary for the 236 back-end storage system employed by the DECADE server. 237 Development of these requirements is guided by a study of the data 238 access patterns used by Target Applications. These requirements 239 should be met by the underlying data transport used by DECADE. In 240 this document, we use "data transport" to refer to a protocol used 241 to read and write data from DECADE in-network storage. 243 Note that a third category also enumerates requirements on the 244 protocol used to discover DECADE Servers. 246 It should also be made clear that the approach is to make DECADE a 247 simple protocol, while still enabling its usage within many Target 248 Applications. For this reason, and to further reinforce the 249 distinction between DECADE and a storage system, in some cases we 250 also highlight the non-requirements of the protocol. These non- 251 requirements are intended to capture behaviors that will NOT be 252 assumed to be needed by DECADE's Target Applications and hence not 253 present in the DECADE protocol. 255 Finally, some implementation considerations are provided, which while 256 not strictly requirements, are intended to provide guidance and 257 highlight potential points that need to be considered by the protocol 258 developers, and later by implementors. 260 4. Protocol Requirements 262 This section details the requirements of DECADE protocol(s). 264 4.1. Overall Protocol Requirements 266 4.1.1. Connectivity Concerns 268 4.1.1.1. NATs and Firewalls 270 REQUIREMENT(S): DECADE client to server protocols SHOULD be usable 271 across firewalls and NAT (Network Address Translation) devices 272 without requiring additional network support (e.g., Application- 273 level Gateways). 275 RATIONALE: Firewalls and NATs are widely used in the Internet today, 276 both in ISP (Internet Service Provider) and Enterprise networks 277 and by consumers. Deployment of DECADE must not require 278 modifications to such devices (beyond, perhaps, reconfiguration). 279 Note that this requirement applies to both any new protocol 280 developed by the DECADE Working Group and any data transport used 281 with DECADE. 283 4.1.1.2. Connections to Clients 285 REQUIREMENT(S): DECADE SHOULD require that network connections be 286 made from DECADE clients to DECADE servers (i.e., not from the 287 server to the DECADE client). 289 RATIONALE: Many household networks and operating systems have 290 firewalls and NATs configured by default to block incoming 291 connections. To ease deployment by avoiding configuration 292 changes and help mitigate security risks, DECADE should not 293 require clients to listen for any incoming network connections 294 (beyond what is required by any other already-deployed 295 application). 297 4.1.2. Security 299 4.1.2.1. Secure Transport 301 REQUIREMENT(S): DECADE MUST contain a mode in which all 302 communication between a DECADE client and server is over a secure 303 transport that provides confidentiality, integrity, and 304 authentication. 306 RATIONALE: Target Applications may wish to write sensitive data. To 307 satisfy this use case, DECADE must provide a mode in which all 308 communication between a DECADE client and server occurs over a 309 secure transport protocol (e.g., SSL/TLS). 311 4.1.3. Error and Failure Conditions 313 4.1.3.1. Overload Condition 315 REQUIREMENT(S): In-network storage, which is operating close to its 316 capacity limit (e.g., too busy servicing other requests), MUST be 317 permitted to reject requests and not be required to generate 318 responses to additional requests. In-network storage MUST also 319 be permitted to redirect requests (see Section 4.1.3.5) as a 320 load-shedding technique. 322 RATIONALE: Forcing the in-network storage to respond to requests 323 when operating close to its capacity can impair its ability to 324 service existing requests, and thus is permitted to avoid 325 generating responses to additional requests. 327 4.1.3.2. Insufficient Resources 329 REQUIREMENT(S): DECADE MUST support an error condition indicating to 330 a DECADE client that resources (e.g., storage space) were not 331 available to service a request (e.g., storage quota exceeded when 332 attempting to write data). 334 RATIONALE: The currently-used resource levels within the in-network 335 storage are not locally-discoverable, since the resources (disk, 336 network interfaces, etc) are not directly attached. In order to 337 allocate resources appropriately amongst remote clients, a client 338 must be able to determine when resource limits have been reached. 339 The client can then respond by explicitly freeing necessary 340 resources or waiting for such resources to be freed. 342 4.1.3.3. Unavailable and Deleted Data 344 REQUIREMENT(S): DECADE MUST support error conditions indicating that 345 (1) data was rejected from being written, (2) deleted, or (3) 346 marked unavailable by a storage provider. 348 RATIONALE: Storage providers may require the ability to (1) avoid 349 storing, (2) delete, or (3) quarantine certain data that has been 350 identified as illegal (or otherwise prohibited). DECADE does not 351 indicate how such data is identified, but applications using 352 DECADE should not break if a storage provider is obligated to 353 enforce such policies. Appropriate error conditions should be 354 indicated to applications. 356 4.1.3.4. Insufficient Permissions 358 REQUIREMENT(S): DECADE MUST support error conditions indicating that 359 the requesting client does not have sufficient permissions to 360 access requested data objects. 362 RATIONALE: DECADE clients may request objects to which they do not 363 have sufficent access permissions, and DECADE servers must be 364 able to signal that this has occurred. Note that access 365 permissions may be insufficient due to a combination of the 366 credentials presented by a client as well as additional policies 367 defined by the storage provider. 369 4.1.3.5. Redirection 371 REQUIREMENT(S): DECADE SHOULD support the ability for a DECADE 372 server to redirect requests to another DECADE server. This may 373 either be in response to an error, failure, or overload 374 condition, or to support capabilities such as load balancing. 376 RATIONALE: A DECADE server may opt to redirect requests to another 377 server to support capabilities such as load balancing, or if the 378 implementation decides that another DECADE server is in a better 379 position to handle the request due to either its location in the 380 network, server status, or other consideration. 382 4.2. Transfer and Latency Requirements 384 4.2.1. Low-Latency Access 385 REQUIREMENT(S): DECADE SHOULD provide "low-latency" access for 386 application clients. DECADE MUST allow clients to specify at 387 least two classes of services: lowest possible latency and 388 latency non-critical. 390 RATIONALE: Some applications may have requirements on delivery time 391 (e.g., live streaming [PPLive]). The user experience may be 392 unsatisfactory if the use of in-network storage results in lower 393 performance than connecting directly to remote clients over a 394 low-speed, possibly congested uplink. Additionally, the overhead 395 required for control-plane operations in DECADE must not cause 396 the latency to be higher than for a low-speed, possibly congested 397 uplink. While it is impossible to make a guarantee that a system 398 using in-network storage will always outperform a system that 399 does not for every transfer, the overall performance of the 400 system should be improved compared with direct low-speed uplink 401 connections, even considering control overhead. 403 4.2.2. Data Object Size 405 REQUIREMENT(S): DECADE MUST allow for efficient data transfer of 406 small objects (e.g., 16KB) between a DECADE client and in-network 407 storage with minimal additional latency imposed by the protocol. 409 RATIONALE: Though Target Applications are frequently used to share 410 large amounts of data (e.g., continuous streams or large files), 411 the data itself is typically subdivided into smaller chunks that 412 are transferred between clients. Additionally, the small chunks 413 may have requirements on delivery time (e.g., in a live-streaming 414 application). DECADE must enable data to be efficiently 415 transferred amongst clients at this granularity. It is important 416 to note that DECADE may be used to store and retrieve larger 417 objects, but protocol(s) should not be designed such that usage 418 with smaller data objects cannot meet the requirements of Target 419 Applications. 421 4.2.3. Communication among DECADE Servers 423 REQUIREMENT(S): DECADE SHOULD support the ability for two in-network 424 storage elements in different administrative domains to write 425 and/or read data directly between each other (if authorized as 426 described in Section 4.7). If such a capability is supported, 427 this MAY be the same (or a subset or extension of) as the DECADE 428 protocol(s) used by clients to access data. 430 RATIONALE: Allowing server-to-server communication can reduce 431 latency in some common scenarios. Consider a scenario when a 432 DECADE client is downloading data into its own storage from 433 another client's in-network storage. One possibility is for the 434 client to first download the data itself, and then upload it to 435 its own storage. However, this uploading causes unnecessary 436 latency and network traffic. Allowing the data to be downloaded 437 from the remote in-network storage into the client's own in- 438 network storage can alleviate both. 440 4.3. Data Access Requirements 442 4.3.1. Reading/Writing Own Storage 444 REQUIREMENT(S): DECADE MUST support the ability for a DECADE client 445 to read data from and write data to its own in-network storage. 447 RATIONALE: Two basic capabilities for any storage system are reading 448 and writing data. A DECADE client can read data from and write 449 data to in-network storage space that it owns. 451 4.3.2. Access by Other Users 453 REQUIREMENT(S): DECADE MUST support the ability for a user to apply 454 access control policies to users other than itself for its 455 storage. The users with whom access is being shared can be under 456 a different administrative domain than the user who owns the in- 457 network storage. The authorized users may read from or write to 458 the user's storage. 460 RATIONALE: Endpoints in Target Applications may be located across 461 multiple ISPs under multiple administrative domains. Thus, to be 462 useful by Target Applications, DECADE allows a user to implement 463 access control policies for users that may or may not be known to 464 the user's storage provider. 466 4.3.3. Negotiable Data Transport Protocol 468 REQUIREMENT(S): DECADE MUST support the ability for a DECADE client 469 to negotiate with its in-network storage about which protocol it 470 can use to read data from and write data to its In-network 471 storage. DECADE MUST specify at least one mandatory protocol to 472 be supported by implementations; usage of a different protocol 473 may be selected via negotiation. 475 RATIONALE: Since typical data transport protocols (e.g., NFS and 476 WebDAV) already provide read and write operations for network 477 storage, it may not be necessary for DECADE to define such 478 operations in a new protocol. However, because of the particular 479 application requirements and deployment considerations, different 480 applications may support different protocols. Thus, a DECADE 481 client must be able to select an appropriate protocol also 482 supported by the in-network storage. This requirement also 483 follows as a result of the requirement of Separation of Control 484 and Data Operations (Section 4.3.4). 486 4.3.4. Separation of Data and Control Policies 488 REQUIREMENT(S): DECADE Protocol(s) MUST only provide a minimal set 489 of core operations to support diverse policies implemented and 490 desired by Target Applications. 492 RATIONALE: Target Applications support many complex behaviors and 493 diverse policies to control and distribute data, such as (e.g., 494 search, index, setting permissions/passing authorization tokens). 495 Thus, to support such Target Applications, these behaviors must 496 be logically separated from the data transfer operations (e.g., 497 read, write). Some minimal overlap (for example obtaining 498 credentials needed to encrypt or authorize data transfer using 499 control operations) may be required to be directly specified by 500 DECADE. 502 4.4. Data Management Requirements 504 4.4.1. Agnostic of reliability 506 REQUIREMENT(S): DECADE SHOULD remain agnostic of reliability/ 507 fault-tolerance level offered by storage provider. 509 RATIONALE: Providers of a DECADE service may wish to offer varying 510 levels of service for different applications/users. However, a 511 single compliant DECADE client should be able to use multiple 512 DECADE services with differing levels of service. 514 4.4.2. Data Object Attributes 516 REQUIREMENT(S): DECADE MUST support the ability to associate 517 attributes with data objects with a scope local to a DECADE 518 server, and for DECADE clients to query these attributes. DECADE 519 protocol(s) MUST transmit any attributes using an operating 520 system-independent and architecture-independent standard format. 521 DECADE protocol(s) MUST be designed such that new attributes can 522 be added by later protocol revisions or extensions. 524 RATIONALE: DECADE supports associating attributes (e.g., a time-to- 525 live, creation timestamp, or object size) with a data object. 526 These attributes are local to a data object stored by a 527 particular DECADE server, and are thus not applied to any DECADE 528 server or client to which the data object is copied. These 529 attributes may be used as hints to the storage system, internal 530 optimizations, or as additional information queryable by DECADE 531 clients. 533 4.4.3. Time-to-live for Written Data Objects 535 REQUIREMENT(S): DECADE MUST support the ability for a DECADE client 536 to indicate a time-to-live value (or expiration time) indicating 537 a length of time until particular data can be deleted by the in- 538 network storage element. 540 RATIONALE: Some data objects written by a DECADE client may be 541 usable only within a certain window of time, such as in live- 542 streaming P2P applications. Providing a time-to-live value for 543 data objects (e.g., at the time they are written) can reduce 544 management overhead by avoiding many 'delete' commands sent to 545 in-network storage. The in-network storage may still keep the 546 data in cache for bandwidth optimization. But this is guided by 547 the privacy policy of the DECADE provider. 549 4.4.4. Offline Usage 551 REQUIREMENT(S): DECADE MAY support the ability for a user to provide 552 authorized access to its in-network storage even if the user has 553 no DECADE applications actively running or connected to the 554 network. 556 RATIONALE: If an application desires, it can authorize remote 557 clients to access its storage even after the application exits or 558 network connectivity is lost. An example use case is mobile 559 scenarios, where a client can lose and regain network 560 connectivity very often. 562 4.5. Data Naming Requirements 564 4.5.1. Unique Names 566 REQUIREMENT(S): DECADE MUST support a naming scheme that ensures a 567 high probability of uniqueness and supports the operation of 568 DECADE servers under diverse administrative domains with no 569 coordination. DECADE SHOULD provide a mechanism (minimally 570 rejection) to handle the improbable case of a collision. 572 RATIONALE: When writing a data object, a DECADE Client should be 573 able to write it without being concerned over whether an object 574 of the same name already exists, unless the existing object 575 contains the exact same data. Note that it may be reasonable for 576 DECADE to satisfy this requirement probabilistically (e.g., using 577 a hashing mechanism). As a result, it is wise to provide a 578 collision handling mechanism, even if the probability of 579 collisions is extremely low. 581 4.6. Resource Control 583 4.6.1. Multiple Applications 585 REQUIREMENT(S): DECADE SHOULD support the ability for users to 586 define resource sharing policies for multiple applications 587 (DECADE clients) being run/managed by the user. 589 RATIONALE: A user may own in-network storage and share the in- 590 network storage resources amongst multiple applications. For 591 example, the user may run one or more video-on-demand 592 application(s) and a live-streaming application(s) which both 593 make use of the user's in-network storage. The applications may 594 be running on different machines and may not directly 595 communicate. Thus, DECADE should enable the user to determine 596 resource sharing policies between the applications. 598 One possibility is for a user to indicate the particular resource 599 sharing policies between applications out-of-band (not using a 600 standard protocol), but this requirement may manifest itself in 601 passing values within DECADE protocol(s) to identify individual 602 applications. Such identifiers can be either user-generated or 603 server-generated and do not need to be registered by IANA. 605 4.6.2. Per-Remote-Client, Per-Data Control 607 REQUIREMENT(S): A DECADE client MUST be able to assign resource 608 policies (bandwidth share, storage quota, and network connection 609 quota) to individual remote clients for reading from and writing 610 particular data to its in-network storage within a particular 611 range of time. The DECADE server MUST enforce these constraints. 613 RATIONALE: Target Applications can rely on control of resources on a 614 per-remote-client or per-data basis. For example, application 615 policy may indicate that certain remote clients have a higher 616 bandwidth share for receiving data [LLSB08]. Additionally, 617 certain data (e.g., chunks) may be distributed with a higher 618 priority. As another example, when allowing a remote client to 619 write data to a user's in-network storage, the remote client may 620 be restricted to write only a certain amount of data. Since the 621 client may need to manage multiple clients accessing its data, it 622 should be able to indicate the time over which the granted 623 resources are usable. For example, an expiration time for the 624 access could be indicated to the server after which no resources 625 are granted (e.g., indicate error as access denied). 627 4.6.3. Server Involvement 629 REQUIREMENT(S): A DECADE client SHOULD be able to indicate to a 630 DECADE server, without itself contacting the server, resource 631 control policies for remote clients' requests. 633 RATIONALE: One important consideration for in-network storage 634 elements is scalability, since a single storage element may be 635 used to support many users. Many Target Applications use small 636 chunk sizes and frequent data exchanges. If such an application 637 employed resource control and contacted the in-network storage 638 element for each data exchange, this could present a scalability 639 challenge for the server as well as additional latency for 640 clients. 642 Our preferred alternative is to let requesting users obtain 643 signed resource control policies (in the form of a token) from 644 the owning user, and then users can then present the policy to 645 the storage directly. This can result in reduced messaging 646 handled by the in-network storage. 648 4.7. Authorization 650 4.7.1. Per-Remote-Client, Per-Data Read Access 652 REQUIREMENT(S): A DECADE Client MUST be able to control which 653 individual remote clients are authorized to read particular data 654 from its in-network storage. 656 RATIONALE: A Target Application can control certain application- 657 level policies by sending particular data (e.g., chunks) to 658 certain remote clients. It is important that remote clients not 659 be able to circumvent such decisions by arbitrarily reading any 660 data in in-network storage. 662 4.7.2. Per-User Write Access 663 REQUIREMENT(S): A DECADE Client MUST be able to control which 664 individual remote clients are authorized to write data into its 665 in-network storage. 667 RATIONALE: The space managed by a user in in-network storage can be 668 a limited resource. At the same time, it can be useful to allow 669 remote clients to write data directly to a user's in-network 670 storage. Thus, a DECADE client should be able to grant only 671 certain remote clients this privilege. 673 4.7.3. Default Access Permissions 675 REQUIREMENT(S): Unless read or write access is granted by a DECADE 676 Client to a remote client, the default access MUST be no access. 678 RATIONALE: The current leading proposal for an access control model 679 in DECADE is via token passing, resulting in a system with little 680 state on the server side. 682 4.7.4. Authorization Checks 684 REQUIREMENT(S): In-network storage MUST check the authorization of a 685 client before it executes a supplied request. The in-network 686 storage MAY use optimizations to avoid such authorization checks 687 as long as the enforced permissions are the same. 689 RATIONALE: Authorization granted by a DECADE client are meaningless 690 unless unauthorized requests are denied access. Thus, the in- 691 network storage element must verify the authorization of a 692 particular request before it is executed. 694 4.7.5. Cryptographic Credentials 696 REQUIREMENT(S): Access MUST be able to be granted using 697 cryptographic credentials. 699 RATIONALE: DECADE clients may be operating on hosts without constant 700 network connectivity or without a permanent attachment address 701 (e.g., mobile devices). To support access control with such 702 hosts, DECADE servers must support access control policies that 703 use cryptographic credentials, not simply by tying access to IP 704 addresses. 706 4.7.6. Server Involvement 707 REQUIREMENT(S): A DECADE client SHOULD be able to indicate, without 708 contacting the server itself, access control policies for remote 709 clients' requests. 711 RATIONALE: See discussion in Section 4.6.3. 713 4.7.7. Protocol Reuse 715 REQUIREMENT(S): If possible, DECADE SHOULD reuse existing protocol 716 and mechanisms for Authentication, Access, and Authorization 717 (AAA). 719 RATIONALE: If possible, reusing an existing AAA protocol/mechanism 720 will minimize the development required by applications, and will 721 maximize interoperability of the DECADE protocol with existing 722 infrastructure. 724 4.8. Non-Requirements 726 4.8.1. Application-defined Properties and Metadata 728 REQUIREMENT(S): DECADE MUST NOT provide a mechanism for associating 729 Application-defined properties (metadata) with data objects 730 beyond what is provided by Section 4.4.2. 732 RATIONALE: Associating key-value pairs that are defined by Target 733 Applications with data objects introduces substantial complexity 734 to the DECADE protocol. If Target Applications wish to associate 735 additional metadata with a data object, possible alternatives 736 include (1) managing such metadata within the Target Application 737 itself, (2) storing metadata inside of the data object, or (3) 738 storing metadata in a different data object at the DECADE server. 740 5. Storage Requirements 742 This section details the requirements of the underlying storage used 743 to support the DECADE protocol(s). 745 5.1. Immutable Data 747 REQUIREMENT(S): DECADE MUST only store and manage data objects that 748 are immutable once they are written to storage. 750 RATIONALE: Immutable data objects are an important simplification in 751 DECADE. Reasonable consistency models for updating existing 752 objects would significantly complicate implementation (especially 753 if implementation chooses to replicate data across multiple 754 servers). If a user needs to update a resource, it can write a 755 new resource and then distribute the new resource instead of the 756 old one. 758 5.2. Explicit Deletion of Data 760 REQUIREMENT(S): DECADE MUST support the ability for a DECADE client 761 to explicitly delete data from its own in-network storage. 763 RATIONALE: A DECADE client may continually be writing data to its 764 in-network storage. Since there may be a limit (e.g., imposed by 765 the storage provider) to how much total storage can be used, some 766 data may need to be removed to make room for additional data. A 767 DECADE client should be able to explicitly remove particular 768 data. This may be implemented using existing protocols. 770 5.3. Multiple writing 772 REQUIREMENT(S): DECADE MUST NOT allow multiple simultaneous writers 773 for the same object. Implementations MUST raise an error to one 774 of the writers. 776 RATIONALE: This avoids data corruption in a simple way while 777 remaining efficient. Alternately, the DECADE server would need 778 to either manage locking, handle write collisions, or merge data, 779 all of which reduce efficiency and increase complexity. 781 5.4. Multiple reading 783 REQUIREMENT(S): DECADE MUST allow for multiple simultaneous readers 784 for an object. 786 RATIONALE: One characteristic of Target Applications is the ability 787 to upload an object to multiple clients. Thus, it is natural for 788 DECADE to allow multiple readers to read the content 789 concurrently. 791 5.5. Reading before completely written 793 REQUIREMENT(S): DECADE MAY allow readers to read from objects before 794 they have been completely written. 796 RATIONALE: Some Target Applications (in particular, P2P streaming) 797 can be sensitive to latency. A technique to reduce latency is to 798 remove store-and-forward delays for data objects (e.g., make the 799 object available before it is completely written). Appropriate 800 handling for error conditions (e.g., a disappearing writer) needs 801 to be specified. 803 5.6. Hints concerning usage of written data 805 REQUIREMENT(S): DECADE MAY allow writers of new objects to indicate 806 specific hints concerning how the objects are expected to be used 807 (e.g., access frequency or time-to-live). 809 RATIONALE: Different Target Applications may have different usage 810 patterns for objects written to in-network storage. For example, 811 a P2P live streaming application may indicate to a DECADE server 812 that the objects are expected to have a short time-to-live, but 813 read frequently. The DECADE server may then opt to persist the 814 objects in memory instead of in disk. 816 5.7. Writing model 818 REQUIREMENT(S): DECADE storage MUST provide at least a writing model 819 (while writing an object) that appends data to data already 820 written. 822 RATIONALE: Depending on the object size (e.g., chunk size) used by a 823 Target Application, the application may need to send data to the 824 DECADE server in multiple packets. To keep implementation 825 simple, the DECADE must at least support the ability to write the 826 data sequentially in the order received. Implementations MAY 827 allow application to write data in an object out-of-order (but 828 MUST NOT overwrite ranges of the object that have already been 829 written). 831 5.8. Storage Status 833 REQUIREMENT(S): A DECADE client MUST be able to read current 834 resource usage (including list of written data objects), resource 835 quotas, and access permissions for its in-network storage. The 836 returned information MUST include resource usage resulting from 837 the client's own usage and usage by other clients that have been 838 authorized to read/write objects or open connections to that 839 client's storage. DECADE protocol(s) MUST support the ability 840 for a DECADE client to read aggregated resource usage information 841 (across all other clients to which it has authorized access), and 842 MAY support the ability to request this information for each 843 other authorized client. 845 RATIONALE: The resources used by a client are not directly-attached 846 (e.g., disk, network interface, etc). Thus, the client cannot 847 locally determine how such resources are being used. Before 848 storing and retrieving data, a client should be able to determine 849 which data is available (e.g., after an application restart). 850 Additionally, a client should be able to determine resource 851 availability to better allocate them to remote clients. Due to 852 scalability issues, it is not required that DECADE support 853 returning usage information broken down by each remote client 854 which has been authorized access, but this feature may be useful 855 in certain deployment scenarios. 857 6. Discovery Requirements 859 6.1. Requirements 861 6.1.1. Locating DECADE Servers 863 REQUIREMENT(S): The DECADE Discovery mechanism MUST allow a DECADE 864 Client to identify one or more DECADE Servers to which it is 865 authorized to read/write data and to which it may authorize other 866 DECADE Clients to read/write data, or fail if no such DECADE 867 Servers are available. 869 RATIONALE: A basic goal of DECADE is to allow DECADE Clients to 870 read/write data for access by other DECADE Clients or itself. 871 Executing the Discovery process should result in a DECADE Client 872 finding a DECADE Server that it can use for these purposes. It 873 is possible that no such DECADE Servers are available. Note that 874 even if a DECADE Client may not successfully locate a DECADE 875 Server that fits these criteria, it may still read/write data 876 from/to a DECADE Server if authorized by another DECADE Client. 878 6.1.2. Support for Clients Behind NATs and Firewalls 880 REQUIREMENT(S): The Discovery mechanism MUST support DECADE Clients 881 operating behind NATs and Firewalls without requiring additional 882 network support (e.g., Application-level Gateways). 884 RATIONALE: NATs and Firewalls are prevalent in network deployments, 885 and it is common for Target Applications that include a DECADE 886 Client to be deployed behind these devices. 888 6.1.3. Prefer Existing Protocols 890 REQUIREMENT(S): The DECADE Server discovery mechanism SHOULD 891 leverage existing mechanisms and protocols wherever possible. 893 RATIONALE: Existing protocols such as DNS and DHCP are widespread. 894 Using existing protocols, or combinations of the protocols that 895 have been specified in other contexts, is strictly preferred over 896 developing a new discovery protocol for DECADE. 898 7. Future Considerations 900 This section enumerates considerations that should be taken into 901 account during the DECADE design and implementation. They have been 902 intentionally omitted as requirements since they are either out of 903 scope or implementation-dependent. Nevertheless, enumerating them 904 may help to guide future application of the requirements included in 905 this document. 907 7.1. Fairness 909 To provide fairness among users, the in-network storage provider 910 should assign resource (e.g., storage, bandwidth, connections) quota 911 for users. This can prevent a small number of clients from occupying 912 large amounts of resources on the in-network storage, while others 913 starve. 915 7.2. Removal of Duplicate Data Objects 917 There are actually two possible scenarios. The first is the case of 918 removing duplicates within one particular DECADE server (or logical 919 server). While not a requirement, as it does not impact the 920 protocol, a DECADE server may implement internal mechanisms to 921 monitor for duplicate objects and use internal mechanisms to prevent 922 duplication in internal storage. 924 The second scenario is removing duplicates across a distributed set 925 of DECADE servers. DECADE does not explicitly design for this, but 926 does offer a redirection mechanism (Section 4.1.3.5) that is one 927 primitive that may be used to support this feature in certain 928 deployment scenarios. 930 7.3. Gaming of the Resource Control Mechanism 932 The particular resource control policy communicated by a DECADE 933 protocol and enforced by the scheduling system of a DECADE 934 implementation may be open to certain gaming by clients. for example 935 by specifying many small peers to increase total throughput or 936 inciting overload conditions at a DECADE server. Identifying and 937 protecting against all such opportunities for gaming is outside the 938 scope of this document, but DECADE protocol(s) and implementations 939 SHOULD be aware that opportunities to game the system may be 940 attempted. 942 8. Security Considerations 944 The security model is an important component of DECADE. It is 945 crucial for users to be able to manage and limit distribution of 946 content to only authorized parties, and the mechanism needs to work 947 on the general Internet which spans multiple administrative and 948 security domains. Previous sections have enumerated detailed 949 requirements, but this section discusses the overall approach and 950 other considerations that do not merit requirements. 952 8.1. Authentication and Authorization 954 DECADE only uses authentication when allowing a particular client to 955 access its own storage at a server. DECADE servers themselves do not 956 authenticate other clients which are reading/writing a client's own 957 storage. Instead, DECADE relies on clients to authenticate others to 958 access its storage, and then communicate the result of that 959 authentication to the DECADE server so that the DECADE server may 960 implement the necessary authorization checks. 962 8.2. Encrypted Data 964 DECADE Servers provide the ability to write raw data objects (subject 965 to any policies instituted by the owner/administrator of the DECADE 966 server, which are outside of the scope of this document). Thus, 967 DECADE clients may opt to encrypt data before it is written to the 968 DECADE Server. However, DECADE itself does not provide encryption of 969 data objects other than is provided by Section 4.1.2.1. 971 9. IANA Considerations 973 There are no IANA considerations with this document. 975 10. References 977 10.1. Normative References 979 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 980 Requirement Levels", BCP 14, RFC 2119, March 1997. 982 10.2. Informative References 984 [I-D.ietf-decade-problem-statement] 985 Song, H., Zong, N., Yang, Y., and R. Alimi, "DECoupled 986 Application Data Enroute (DECADE) Problem Statement", 987 draft-ietf-decade-problem-statement-03 (work in progress), 988 March 2011. 990 [I-D.ietf-decade-arch] 991 Alimi, R., Yang, Y., Rahman, A., Kutscher, D., and H. Liu, 992 "DECADE Architecture", draft-ietf-decade-arch-02 (work in 993 progress), July 2011. 995 [LLSB08] Levin, D., LaCurts, K., Spring, N., and B. Bhattacharjee, 996 "BitTorrent is an Auction: Analyzing and Improving 997 BitTorrent's Incentives", SIGCOMM 2008, August 2008. 999 [PPLive] "PPLive", . 1001 Appendix A. Acknowledgments 1003 We would also like to thank Haibin Song for substantial contributions 1004 to earlier versions of this document. We would also like to thank 1005 Reinaldo Penno, Alexey Melnikov, Rich Woundy, Ning Zong, Roni Even, 1006 David McDysan, Borje Ohlman, Dirk Kutscher, Akbar Rahman, Xiao Zhu, 1007 Yunfei Zhang, and Jin Peng for contributions and general feedback. 1009 Authors' Addresses 1011 Yingjie Gu 1012 Huawei 1013 No. 101 Software Avenue 1014 Nanjing, Jiangsu Province 210012 1015 P.R.China 1017 Phone: +86-25-56624760 1018 Email: guyingjie@huawei.com 1020 David A. Bryan 1021 Polycom, Inc. 1023 Email: dbryan@ethernot.org 1025 Yang Richard Yang 1026 Yale University 1028 Email: yry@cs.yale.edu 1029 Richard Alimi 1030 Google 1032 Email: ralimi@google.com