idnits 2.17.1 draft-ietf-decade-reqs-04.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 (September 28, 2011) is 4584 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: March 31, 2012 Polycom, Inc. 6 Y. Yang 7 Yale University 8 R. Alimi 9 Google 10 September 28, 2011 12 DECADE Requirements 13 draft-ietf-decade-reqs-04 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 March 31, 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 . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . . . . . 7 86 4.1.2.1. Secure Transport . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . . . . 16 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 . . . . . . . . . . . . . . . . 17 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 . . . . . . . . . . 18 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. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 20 139 7.1. Non-DECADE Internal Protocols . . . . . . . . . . . . . . 20 140 7.2. Fairness . . . . . . . . . . . . . . . . . . . . . . . . . 21 141 7.3. Removal of Duplicate Data Objects . . . . . . . . . . . . 21 142 7.4. Gaming of the Resource Control Mechanism . . . . . . . . . 21 143 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 144 8.1. Authentication and Authorization . . . . . . . . . . . . . 22 145 8.2. Encrypted Data . . . . . . . . . . . . . . . . . . . . . . 22 146 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 147 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 148 10.1. Normative References . . . . . . . . . . . . . . . . . . . 22 149 10.2. Informative References . . . . . . . . . . . . . . . . . . 22 150 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 23 151 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 153 1. Introduction 155 The object of DECoupled Application Data Enroute (DECADE) is to 156 provide an open and standard in-network storage system for content 157 distribution applications, where data is typically broken into one or 158 more chunks and then distributed. This may already include many 159 types of applications including P2P applications, IPTV (Internet 160 Protocol Television), and VoD (Video on Demand). (For a precise 161 definition of the applications targeted in DECADE, see the definition 162 for Target Application in Section 2.) Instead of always transferring 163 data directly from a source/owner client to a requesting client, the 164 source/owner client can write to and manage its content on its in- 165 network storage. The requesting client can get the address of the 166 in-network storage pertaining to the source/owner client and read 167 data from the storage. 169 This draft enumerates and explains the rationale behind SPECIFIC 170 requirements on the protocol design and on any data store 171 implementation that may be used to implement DECADE servers that 172 should be considered during the design and implementation of a DECADE 173 system. As such, it DOES NOT include general guiding principles. 174 General design considerations, explanation of the problem being 175 addressed, and enumeration of the types of applications to which 176 DECADE may be suited is not considered in this document. For general 177 information, please see the problem statement 178 [I-D.ietf-decade-problem-statement] and architecture 179 [I-D.ietf-decade-arch] drafts. 181 This document enumerates the requirements to enable target 182 applications to utilize in-network storage. In this context, using 183 storage resources includes not only basic capabilities such as 184 writing, reading, and managing data, but also controlling access for 185 particular remote clients with which it is sharing data. 186 Additionally, we also consider controlling the resources used by 187 remote clients when they access data as an integral part of utilizing 188 the network storage. 190 2. Terminology and Concepts 192 This document uses terms defined in 193 [I-D.ietf-decade-problem-statement]. 195 This document also defines additional terminology: 197 Target Application: An application (typically installed at end-hosts) 198 with the ability to explicitly control usage of network and/or 199 storage resources to deliver content to a large number of users. 201 This includes scenarios where multiple applications or entities 202 cooperate, such as with P2P, CDN, and hybrid P2P/CDN architectures. 203 Such applications distribute large amounts of content (e.g., a large 204 file, or video stream) by dividing the content into smaller blocks 205 for more flexible distribution (e.g., over multiple application-level 206 paths). The distributed content is typically immutable (though it 207 may be deleted). We use the term Target Application to refer to the 208 type of applications that are explicitly (but not exclusively) 209 supported by DECADE. 211 3. Requirements Structure 213 The DECADE protocol is intended to sit between Target Applications 214 and a back-end storage system. DECADE does not intend to develop yet 215 another storage system, but rather to create a protocol that enables 216 Target Applications to make use of storage within the network, 217 leaving specific storage system considerations to the implementation 218 of the DECADE servers as much as possible. For this reason, we have 219 divided the requirements into two primary categories: 221 o Protocol Requirements: Protocol requirements for Target 222 Applications to make use of in-network storage within their own 223 data dissemination schemes. Development of these requirements is 224 guided by a study of data access, search and management 225 capabilities used by Target Applications. These requirements may 226 be met by a combination of existing protocols and new protocols to 227 be defined within the DECADE Working Group. 229 o Storage Requirements: Functional requirements necessary for the 230 back-end storage system employed by the DECADE server. 231 Development of these requirements is guided by a study of the data 232 access patterns used by Target Applications. These requirements 233 should be met by the underlying data transport used by DECADE. In 234 this document, we use "data transport" to refer to a protocol used 235 to read and write data from DECADE in-network storage. 237 Note that a third category also enumerates requirements on the 238 protocol used to discover DECADE Servers. 240 It should also be made clear that the approach is to make DECADE a 241 simple protocol, while still enabling its usage within many Target 242 Applications. For this reason, and to further reinforce the 243 distinction between DECADE and a storage system, in some cases we 244 also highlight the non-requirements of the protocol. These non- 245 requirements are intended to capture behaviors that will NOT be 246 assumed to be needed by DECADE's Target Applications and hence not 247 present in the DECADE protocol. 249 Finally, some implementation considerations are provided, which while 250 not strictly requirements, are intended to provide guidance and 251 highlight potential points that need to be considered by the protocol 252 developers, and later by implementors. 254 4. Protocol Requirements 256 This section details the requirements of DECADE protocol(s). 258 4.1. Overall Protocol Requirements 260 4.1.1. Connectivity Concerns 262 4.1.1.1. NATs and Firewalls 264 REQUIREMENT(S): DECADE SHOULD be usable across firewalls and NAT 265 (Network Address Translation) devices without requiring 266 additional network support (e.g., Application-level Gateways). 268 RATIONALE: Firewalls and NATs are widely used in the Internet today, 269 both in ISP (Internet Service Provider) and Enterprise networks 270 and by consumers. Deployment of DECADE must not require 271 modifications to such devices (beyond, perhaps, reconfiguration). 272 Note that this requirement applies to both any new protocol 273 developed by the DECADE Working Group and any data transport used 274 with DECADE. 276 4.1.1.2. Connections to Clients 278 REQUIREMENT(S): DECADE SHOULD require that network connections be 279 made from DECADE clients to DECADE servers (i.e., not from the 280 server to the DECADE client). 282 RATIONALE: Many household networks and operating systems have 283 firewalls and NATs configured by default to block incoming 284 connections. To ease deployment by avoiding configuration 285 changes and help mitigate security risks, DECADE should not 286 require clients to listen for any incoming network connections 287 (beyond what is required by any other already-deployed 288 application). 290 4.1.2. Security 292 4.1.2.1. Secure Transport 293 REQUIREMENT(S): DECADE MUST contain a mode in which all 294 communication between a DECADE client and server is over a secure 295 transport that provides confidentiality, integrity, and 296 authentication. 298 RATIONALE: Target Applications may wish to write sensitive data. To 299 satisfy this use case, DECADE must provide a mode in which all 300 communication between a DECADE client and server occurs over a 301 secure transport protocol (e.g., SSL/TLS). 303 4.1.3. Error and Failure Conditions 305 4.1.3.1. Overload Condition 307 REQUIREMENT(S): In-network storage, which is operating close to its 308 capacity limit (e.g., too busy servicing other requests), MUST be 309 permitted to reject requests and not be required to generate 310 responses to additional requests. In-network storage MUST also 311 be permitted to redirect requests (see Section 4.1.3.5) as a 312 load-shedding technique. 314 RATIONALE: Forcing the in-network storage to respond to requests 315 when operating close to its capacity can impair its ability to 316 service existing requests, and thus is permitted to avoid 317 generating responses to additional requests. 319 4.1.3.2. Insufficient Resources 321 REQUIREMENT(S): DECADE MUST support an error condition indicating to 322 a DECADE client that resources (e.g., storage space) were not 323 available to service a request (e.g., storage quota exceeded when 324 attempting to write data). 326 RATIONALE: The currently-used resource levels within the in-network 327 storage are not locally-discoverable, since the resources (disk, 328 network interfaces, etc) are not directly attached. In order to 329 allocate resources appropriately amongst remote clients, a client 330 must be able to determine when resource limits have been reached. 331 The client can then respond by explicitly freeing necessary 332 resources or waiting for such resources to be freed. 334 4.1.3.3. Unavailable and Deleted Data 336 REQUIREMENT(S): DECADE MUST support error conditions indicating that 337 (1) data was rejected from being written, (2) deleted, or (3) 338 marked unavailable by a storage provider. 340 RATIONALE: Storage providers may require the ability to (1) avoid 341 storing, (2) delete, or (3) quarantine certain data that has been 342 identified as illegal (or otherwise prohibited). DECADE does not 343 indicate how such data is identified, but applications using 344 DECADE should not break if a storage provider is obligated to 345 enforce such policies. Appropriate error conditions should be 346 indicated to applications. 348 4.1.3.4. Insufficient Permissions 350 REQUIREMENT(S): DECADE MUST support error conditions indicating that 351 the requesting client does not have sufficient permissions to 352 access requested data objects. 354 RATIONALE: DECADE clients may request objects to which they do not 355 have sufficent access permissions, and DECADE servers must be 356 able to signal that this has occurred. Note that access 357 permissions may be insufficient due to a combination of the 358 credentials presented by a client as well as additional policies 359 defined by the storage provider. 361 4.1.3.5. Redirection 363 REQUIREMENT(S): DECADE SHOULD support the ability for a DECADE 364 server to redirect requests to another DECADE server. This may 365 either be in response to an error, failure, or overload 366 condition, or to support capabilities such as load balancing. 368 RATIONALE: A DECADE server may opt to redirect requests to another 369 server to support capabilities such as load balancing, or if the 370 implementation decides that another DECADE server is in a better 371 position to handle the request due to either its location in the 372 network, server status, or other consideration. 374 4.2. Transfer and Latency Requirements 376 4.2.1. Low-Latency Access 378 REQUIREMENT(S): DECADE SHOULD provide "low-latency" access for 379 application clients. DECADE MUST allow clients to specify at 380 least two classes of services for service: lowest possible 381 latency and latency non-critical. 383 RATIONALE: Some applications may have requirements on delivery time 384 (e.g., live streaming [PPLive]). The user experience may be 385 unsatisfactory if the use of in-network storage results in lower 386 performance than connecting directly to remote clients over a 387 low-speed, possibly congested uplink. Additionally, the overhead 388 required for control-plane operations in DECADE must not cause 389 the latency to be higher than for a low-speed, possibly congested 390 uplink. While it is impossible to make a guarantee that a system 391 using in-network storage will always outperform a system that 392 does not for every transfer, the overall performance of the 393 system should be improved compared with direct low-speed uplink 394 connections, even considering control overhead. 396 4.2.2. Data Object Size 398 REQUIREMENT(S): DECADE MUST allow for efficient data transfer of 399 small objects (e.g., 16KB) between a DECADE client and in-network 400 storage with minimal additional latency imposed by the protocol. 402 RATIONALE: Though Target Applications are frequently used to share 403 large amounts of data (e.g., continuous streams or large files), 404 the data itself is typically subdivided into smaller chunks that 405 are transferred between clients. Additionally, the small chunks 406 may have requirements on delivery time (e.g., in a live-streaming 407 application). DECADE must enable data to be efficiently 408 transferred amongst clients at this granularity. It is important 409 to note that DECADE may be used to store and retrieve larger 410 objects, but protocol(s) should not be designed such that usage 411 with smaller data objects cannot meet the requirements of Target 412 Applications. 414 4.2.3. Communication among DECADE Servers 416 REQUIREMENT(S): DECADE SHOULD support the ability for two in-network 417 storage elements in different administrative domains to write 418 and/or read data directly between each other (if authorized as 419 described in Section 4.7). If such a capability is supported, 420 this MAY be the same (or a subset or extension of) as the DECADE 421 protocol(s) used by clients to access data. 423 RATIONALE: Allowing server-to-server communication can reduce 424 latency in some common scenarios. Consider a scenario when a 425 DECADE client is downloading data into its own storage from 426 another client's in-network storage. One possibility is for the 427 client to first download the data itself, and then upload it to 428 its own storage. However, this uploading causes unnecessary 429 latency and network traffic. Allowing the data to be downloaded 430 from the remote in-network storage into the client's own in- 431 network storage can alleviate both. 433 4.3. Data Access Requirements 435 4.3.1. Reading/Writing Own Storage 437 REQUIREMENT(S): DECADE MUST support the ability for a DECADE client 438 to read data from and write data to its own in-network storage. 440 RATIONALE: Two basic capabilities for any storage system are reading 441 and writing data. A DECADE client can read data from and write 442 data to in-network storage space that it owns. 444 4.3.2. Access by Other Users 446 REQUIREMENT(S): DECADE MUST support the ability for a user to apply 447 access control policies to users other than itself for its 448 storage. The users with whom access is being shared can be under 449 a different administrative domain than the user who owns the in- 450 network storage. The authorized users may read from or write to 451 the user's storage. 453 RATIONALE: Endpoints in Target Applications may be located across 454 multiple ISPs under multiple administrative domains. Thus, to be 455 useful by Target Applications, DECADE allows a user to implement 456 access control policies for users that may or may not be known to 457 the user's storage provider. 459 4.3.3. Negotiable Data Transport Protocol 461 REQUIREMENT(S): DECADE MUST support the ability for a DECADE client 462 to negotiate with its in-network storage about which protocol it 463 can use to read data from and write data to its In-network 464 storage. DECADE MUST specify at least one mandatory protocol to 465 be supported by implementations; usage of a different protocol 466 may be selected via negotiation. 468 RATIONALE: Since typical data transport protocols (e.g., NFS and 469 WebDAV) already provide read and write operations for network 470 storage, it may not be necessary for DECADE to define such 471 operations in a new protocol. However, because of the particular 472 application requirements and deployment considerations, different 473 applications may support different protocols. Thus, a DECADE 474 client must be able to select an appropriate protocol also 475 supported by the in-network storage. This requirement also 476 follows as a result of the requirement of Separation of Control 477 and Data Operations (Section 4.3.4). 479 4.3.4. Separation of Data and Control Policies 481 REQUIREMENT(S): DECADE Protocol(s) MUST only provide a minimal set 482 of core operations to support diverse policies implemented and 483 desired by Target Applications. 485 RATIONALE: Target Applications support many complex behaviors and 486 diverse policies to control and distribute data, such as (e.g., 487 search, index, setting permissions/passing authorization tokens). 488 Thus, to support such Target Applications, these behaviors must 489 be logically separated from the data transfer operations (e.g., 490 read, write). Some minimal overlap (for example obtaining 491 credentials needed to encrypt or authorize data transfer using 492 control operations) may be required to be directly specified by 493 DECADE. 495 4.4. Data Management Requirements 497 4.4.1. Agnostic of reliability 499 REQUIREMENT(S): DECADE SHOULD remain agnostic of reliability/ 500 fault-tolerance level offered by storage provider. 502 RATIONALE: Providers of a DECADE service may wish to offer varying 503 levels of service for different applications/users. However, a 504 single compliant DECADE client should be able to use multiple 505 DECADE services with differing levels of service. 507 4.4.2. Data Object Attributes 509 REQUIREMENT(S): DECADE MUST support the ability to associate 510 attributes with data objects with a scope local to a DECADE 511 server, and for DECADE clients to query these attributes. DECADE 512 protocol(s) MUST transmit any attributes using an operating 513 system-independent and architecture-independent standard format. 514 DECADE protocol(s) MUST be designed such that new attributes can 515 be added by later protocol revisions or extensions. 517 RATIONALE: DECADE supports associating attributes (e.g., a time-to- 518 live, creation timestamp, or object size) with a data object. 519 These attributes are local to a data object stored by a 520 particular DECADE server, and are thus not applied to any DECADE 521 server or client to which the data object is copied. These 522 attributes may be used as hints to the storage system, internal 523 optimizations, or as additional information queryable by DECADE 524 clients. 526 4.4.3. Time-to-live for Written Data Objects 528 REQUIREMENT(S): DECADE MUST support the ability for a DECADE client 529 to indicate a time-to-live value (or expiration time) indicating 530 a length of time until particular data can be deleted by the in- 531 network storage element. 533 RATIONALE: Some data objects written by a DECADE client may be 534 usable only within a certain window of time, such as in live- 535 streaming P2P applications. Providing a time-to-live value for 536 data objects (e.g., at the time they are written) can reduce 537 management overhead by avoiding many 'delete' commands sent to 538 in-network storage. The in-network storage may still keep the 539 data in cache for bandwidth optimization. But this is guided by 540 the privacy policy of the DECADE provider. 542 4.4.4. Offline Usage 544 REQUIREMENT(S): DECADE MAY support the ability for a user to provide 545 authorized access to its in-network storage even if the user has 546 no DECADE applications actively running or connected to the 547 network. 549 RATIONALE: If an application desires, it can authorize remote 550 clients to access its storage even after the application exits or 551 network connectivity is lost. An example use case is mobile 552 scenarios, where a client can lose and regain network 553 connectivity very often. 555 4.5. Data Naming Requirements 557 4.5.1. Unique Names 559 REQUIREMENT(S): DECADE MUST support a naming scheme that ensures a 560 high probability of uniqueness and supports the operation of 561 DECADE servers under diverse administrative domains with no 562 coordination. DECADE SHOULD provide a mechanism (minimally 563 rejection) to handle the improbable case of a collision. 565 RATIONALE: When writing a data object, a DECADE Client should be 566 able to write it without being concerned over whether an object 567 of the same name already exists, unless the existing object 568 contains the exact same data. Note that it may be reasonable for 569 DECADE to satisfy this requirement probabilistically (e.g., using 570 a hashing mechanism). As a result, it is wise to provide a 571 collision handling mechanism, even if the probability of 572 collisions is extremely low. 574 4.6. Resource Control 576 4.6.1. Multiple Applications 578 REQUIREMENT(S): DECADE SHOULD support the ability for users to 579 define resource sharing policies for multiple applications 580 (DECADE clients) being run/managed by the user. 582 RATIONALE: A user may own in-network storage and share the in- 583 network storage resources amongst multiple applications. For 584 example, the user may run one or more video-on-demand 585 application(s) and a live-streaming application(s) which both 586 make use of the user's in-network storage. The applications may 587 be running on different machines and may not directly 588 communicate. Thus, DECADE should enable the user to determine 589 resource sharing policies between the applications. 591 One possibility is for a user to indicate the particular resource 592 sharing policies between applications out-of-band (not using a 593 standard protocol), but this requirement may manifest itself in 594 passing values within DECADE protocol(s) to identify individual 595 applications. Such identifiers can be either user-generated or 596 server-generated and do not need to be registered by IANA. 598 4.6.2. Per-Remote-Client, Per-Data Control 600 REQUIREMENT(S): A DECADE client MUST be able to assign resource 601 policies (bandwidth share, storage quota, and network connection 602 quota) to individual remote clients for reading from and writing 603 particular data to its in-network storage within a particular 604 range of time. The DECADE server MUST enforce these constraints. 606 RATIONALE: Target Applications can rely on control of resources on a 607 per-remote-client or per-data basis. For example, application 608 policy may indicate that certain remote clients have a higher 609 bandwidth share for receiving data [LLSB08]. Additionally, 610 certain data (e.g., chunks) may be distributed with a higher 611 priority. As another example, when allowing a remote client to 612 write data to a user's in-network storage, the remote client may 613 be restricted to write only a certain amount of data. Since the 614 client may need to manage multiple clients accessing its data, it 615 should be able to indicate the time over which the granted 616 resources are usable. For example, an expiration time for the 617 access could be indicated to the server after which no resources 618 are granted (e.g., indicate error as access denied). 620 4.6.3. Server Involvement 622 REQUIREMENT(S): A DECADE client SHOULD be able to indicate to a 623 DECADE server, without itself contacting the server, resource 624 control policies for remote clients' requests. 626 RATIONALE: One important consideration for in-network storage 627 elements is scalability, since a single storage element may be 628 used to support many users. Many Target Applications use small 629 chunk sizes and frequent data exchanges. If such an application 630 employed resource control and contacted the in-network storage 631 element for each data exchange, this could present a scalability 632 challenge for the server as well as additional latency for 633 clients. 635 Our preferred alternative is to let requesting users obtain 636 signed resource control policies (in the form of a token) from 637 the owning user, and then users can then present the policy to 638 the storage directly. This can result in reduced messaging 639 handled by the in-network storage. 641 4.7. Authorization 643 4.7.1. Per-Remote-Client, Per-Data Read Access 645 REQUIREMENT(S): A DECADE Client MUST be able to control which 646 individual remote clients are authorized to read particular data 647 from its in-network storage. 649 RATIONALE: A Target Application can control certain application- 650 level policies by sending particular data (e.g., chunks) to 651 certain remote clients. It is important that remote clients not 652 be able to circumvent such decisions by arbitrarily reading any 653 data in in-network storage. 655 4.7.2. Per-User Write Access 657 REQUIREMENT(S): A DECADE Client MUST be able to control which 658 individual remote clients are authorized to write data into its 659 in-network storage. 661 RATIONALE: The space managed by a user in in-network storage can be 662 a limited resource. At the same time, it can be useful to allow 663 remote clients to write data directly to a user's in-network 664 storage. Thus, a DECADE client should be able to grant only 665 certain remote clients this privilege. 667 4.7.3. Default Access Permissions 669 REQUIREMENT(S): Unless read or write access is granted by a DECADE 670 Client to a remote client, the default access MUST be no access. 672 RATIONALE: The current leading proposal for an access control model 673 in DECADE is via token passing, resulting in a system with little 674 state on the server side. 676 4.7.4. Authorization Checks 678 REQUIREMENT(S): In-network storage MUST check the authorization of a 679 client before it executes a supplied request. The in-network 680 storage MAY use optimizations to avoid such authorization checks 681 as long as the enforced permissions are the same. 683 RATIONALE: Authorization granted by a DECADE client are meaningless 684 unless unauthorized requests are denied access. Thus, the in- 685 network storage element must verify the authorization of a 686 particular request before it is executed. 688 4.7.5. Cryptographic Credentials 690 REQUIREMENT(S): Access MUST be able to be granted using 691 cryptographic credentials. 693 RATIONALE: DECADE clients may be operating on hosts without constant 694 network connectivity or without a permanent attachment address 695 (e.g., mobile devices). To support access control with such 696 hosts, DECADE servers must support access control policies that 697 use cryptographic credentials, not simply by tying access to IP 698 addresses. 700 4.7.6. Server Involvement 702 REQUIREMENT(S): A DECADE client SHOULD be able to indicate, without 703 contacting the server itself, access control policies for remote 704 clients' requests. 706 RATIONALE: See discussion in Section 4.6.3. 708 4.7.7. Protocol Reuse 710 REQUIREMENT(S): If possible, DECADE SHOULD reuse existing protocol 711 and mechanisms for Authentication, Access, and Authorization 712 (AAA). 714 RATIONALE: If possible, reusing an existing AAA protocol/mechanism 715 will minimize the development required by applications, and will 716 maximize interoperability of the DECADE protocol with existing 717 infrastructure. 719 4.8. Non-Requirements 721 4.8.1. Application-defined Properties and Metadata 723 REQUIREMENT(S): DECADE MUST NOT provide a mechanism for associating 724 Application-defined properties (metadata) with data objects 725 beyond what is provided by Section 4.4.2. 727 RATIONALE: Associating key-value pairs that are defined by Target 728 Applications with data objects introduces substantial complexity 729 to the DECADE protocol. If Target Applications wish to associate 730 additional metadata with a data object, possible alternatives 731 include (1) managing such metadata within the Target Application 732 itself, (2) storing metadata inside of the data object, or (3) 733 storing metadata in a different data object at the DECADE server. 735 5. Storage Requirements 737 This section details the requirements of the underlying storage used 738 to support the DECADE protocol(s). 740 5.1. Immutable Data 742 REQUIREMENT(S): DECADE MUST provide the ability to manage data 743 objects that are immutable once they are written to storage. 745 RATIONALE: Immutable data objects are an important simplification in 746 DECADE. Reasonable consistency models for updating existing 747 objects would significantly complicate implementation (especially 748 if implementation chooses to replicate data across multiple 749 servers). If a user needs to update a resource, it can write a 750 new resource and then distribute the new resource instead of the 751 old one. 753 5.2. Explicit Deletion of Data 755 REQUIREMENT(S): DECADE MUST support the ability for a DECADE client 756 to explicitly delete data from its own in-network storage. 758 RATIONALE: A DECADE client may continually be writing data to its 759 in-network storage. Since there may be a limit (e.g., imposed by 760 the storage provider) to how much total storage can be used, some 761 data may need to be removed to make room for additional data. A 762 DECADE client should be able to explicitly remove particular 763 data. This may be implemented using existing protocols. 765 5.3. Multiple writing 767 REQUIREMENT(S): DECADE MUST NOT allow multiple simultaneous writers 768 for the same object. Implementations MUST raise an error to one 769 of the writers. 771 RATIONALE: This avoids data corruption in a simple way while 772 remaining efficient. Alternately, the DECADE server would need 773 to either manage locking, handle write collisions, or merge data, 774 all of which reduce efficiency and increase complexity. 776 5.4. Multiple reading 778 REQUIREMENT(S): DECADE MUST allow for multiple simultaneous readers 779 for an object. 781 RATIONALE: One characteristic of Target Applications is the ability 782 to upload an object to multiple clients. Thus, it is natural for 783 DECADE to allow multiple readers to read the content 784 concurrently. 786 5.5. Reading before completely written 788 REQUIREMENT(S): DECADE MAY allow readers to read from objects before 789 they have been completely written. 791 RATIONALE: Some Target Applications (in particular, P2P streaming) 792 can be sensitive to latency. A technique to reduce latency is to 793 remove store-and-forward delays for data objects (e.g., make the 794 object available before it is completely written). Appropriate 795 handling for error conditions (e.g., a disappearing writer) needs 796 to be specified. 798 5.6. Hints concerning usage of written data 800 REQUIREMENT(S): DECADE MAY allow writers of new objects to indicate 801 specific hints concerning how the objects are expected to be used 802 (e.g., access frequency or time-to-live). 804 RATIONALE: Different Target Applications may have different usage 805 patterns for objects written to in-network storage. For example, 806 a P2P live streaming application may indicate to a DECADE server 807 that the objects are expected to have a short time-to-live, but 808 read frequently. The DECADE server may then opt to persist the 809 objects in memory instead of in disk. 811 5.7. Writing model 813 REQUIREMENT(S): DECADE storage MUST provide at least a writing model 814 (while writing an object) that appends data to data already 815 written. 817 RATIONALE: Depending on the object size (e.g., chunk size) used by a 818 Target Application, the application may need to send data to the 819 DECADE server in multiple packets. To keep implementation 820 simple, the DECADE must at least support the ability to write the 821 data sequentially in the order received. Implementations MAY 822 allow application to write data in an object out-of-order (but 823 MUST NOT overwrite ranges of the object that have already been 824 written). 826 5.8. Storage Status 828 REQUIREMENT(S): A DECADE client MUST be able to read current 829 resource usage (including list of written data objects), resource 830 quotas, and access permissions for its in-network storage. The 831 returned information MUST include resource usage resulting from 832 the client's own usage and usage by other clients that have been 833 authorized to read/write objects or open connections to that 834 client's storage. DECADE protocol(s) MUST support the ability 835 for a DECADE client to read aggregated resource usage information 836 (across all other clients to which it has authorized access), and 837 MAY support the ability to request this information for each 838 other authorized client. 840 RATIONALE: The resources used by a client are not directly-attached 841 (e.g., disk, network interface, etc). Thus, the client cannot 842 locally determine how such resources are being used. Before 843 storing and retrieving data, a client should be able to determine 844 which data is available (e.g., after an application restart). 845 Additionally, a client should be able to determine resource 846 availability to better allocate them to remote clients. Due to 847 scalability issues, it is not required that DECADE support 848 returning usage information broken down by each remote client 849 which has been authorized access, but this feature may be useful 850 in certain deployment scenarios. 852 6. Discovery Requirements 854 6.1. Requirements 856 6.1.1. Locating DECADE Servers 858 REQUIREMENT(S): The DECADE Discovery mechanism MUST allow a DECADE 859 Client to identify one or more DECADE Servers to which it is 860 authorized to read/write data and to which it may authorize other 861 DECADE Clients to read/write data, or fail if no such DECADE 862 Servers are available. 864 RATIONALE: A basic goal of DECADE is to allow DECADE Clients to 865 read/write data for access by other DECADE Clients or itself. 866 Executing the Discovery process should result in a DECADE Client 867 finding a DECADE Server that it can use for these purposes. It 868 is possible that no such DECADE Servers are available. Note that 869 even if a DECADE Client may not successfully locate a DECADE 870 Server that fits these criteria, it may still read/write data a 871 DECADE Server if authorized by another DECADE Client. 873 6.1.2. Support for Clients Behind NATs and Firewalls 875 REQUIREMENT(S): The Discovery mechanism MUST support DECADE Clients 876 operating behind NATs and Firewalls without requiring additional 877 network support (e.g., Application-level Gateways). 879 RATIONALE: NATs and Firewalls are prevalent in network deployments, 880 and it is common for Target Applications that include a DECADE 881 Client to be deployed behind these devices. 883 6.1.3. Prefer Existing Protocols 885 REQUIREMENT(S): The DECADE Server discovery mechanism SHOULD 886 leverage existing mechanisms and protocols wherever possible. 888 RATIONALE: Existing protocols such as DNS and DHCP are widespread. 889 Using existing protocols, or combinations of the protocols that 890 have been specified in other contexts, is strictly preferred over 891 developing a new discovery protocol for DECADE. 893 7. Discussion 895 7.1. Non-DECADE Internal Protocols 897 Sometimes, several logical in-network storage systems could be 898 deployed on the same physical network device. In this case, in- 899 network storages on the same physical network device can communicate 900 and transfer data through internal communication messages. However 901 in-network storages deployed on different physical network devices 902 SHOULD communicate with DECADE protocol(s). 904 7.2. Fairness 906 To provide fairness among users, the in-network storage provider 907 should assign resource (e.g., storage, bandwidth, connections) quota 908 for users. This can prevent a small number of clients from occupying 909 large amounts of resources on the in-network storage, while others 910 starve. 912 7.3. Removal of Duplicate Data Objects 914 There are actually two possible scenarios. The first is the case of 915 removing duplicates within one particular DECADE server (or logical 916 server). While not a requirement, as it does not impact the 917 protocol, a DECADE server may implement internal mechanisms to 918 monitor for duplicate objects and use internal mechanisms to prevent 919 duplication in internal storage. 921 The second scenario is removing duplicates across a distributed set 922 of DECADE servers. DECADE does not explicitly design for this, but 923 does offer a redirection mechanism (Section 4.1.3.5) that is one 924 primitive that may be used to support this feature in certain 925 deployment scenarios. 927 7.4. Gaming of the Resource Control Mechanism 929 The particular resource control policy communicated by a DECADE 930 protocol and enforced by the scheduling system of a DECADE 931 implementation may be open to certain gaming by clients. for example 932 by specifying many small peers to increase total throughput or 933 inciting overload conditions at a DECADE server. Identifying and 934 protecting against all such opportunities for gaming is outside the 935 scope of this document, but DECADE protocol(s) and implementations 936 SHOULD be aware that opportunities to game the system may be 937 attempted. 939 8. Security Considerations 941 The security model is an important component of DECADE. It is 942 crucial for users to be able to manage and limit distribution of 943 content to only authorized parties, and the mechanism needs to work 944 on the general Internet which spans multiple administrative and 945 security domains. Previous sections have enumerated detailed 946 requirements, but this section discusses the overall approach and 947 other considerations that do not merit requirements. 949 8.1. Authentication and Authorization 951 DECADE only uses authentication when allowing a particular client to 952 access its own storage at a server. DECADE servers themselves do not 953 authenticate other clients which are reading/writing a client's own 954 storage. Instead, DECADE relies on clients to authenticate others to 955 access its storage, and then communicate the result of that 956 authentication to the DECADE server so that the DECADE server may 957 implement the necessary authorization checks. 959 8.2. Encrypted Data 961 DECADE Servers provide the ability to write raw data objects (subject 962 to any policies instituted by the owner/administrator of the DECADE 963 server, which are outside of the scope of this document). Thus, 964 DECADE clients may opt to encrypt data before it is written to the 965 DECADE Server. However, DECADE itself does not provide encryption of 966 data objects other than is provided by Section 4.1.2.1. 968 9. IANA Considerations 970 There are no IANA considerations with this document. 972 10. References 974 10.1. Normative References 976 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 977 Requirement Levels", BCP 14, RFC 2119, March 1997. 979 10.2. Informative References 981 [I-D.ietf-decade-problem-statement] 982 Song, H., Zong, N., Yang, Y., and R. Alimi, "DECoupled 983 Application Data Enroute (DECADE) Problem Statement", 984 draft-ietf-decade-problem-statement-03 (work in progress), 985 March 2011. 987 [I-D.ietf-decade-arch] 988 Alimi, R., Yang, Y., Rahman, A., Kutscher, D., and H. Liu, 989 "DECADE Architecture", draft-ietf-decade-arch-02 (work in 990 progress), July 2011. 992 [LLSB08] Levin, D., LaCurts, K., Spring, N., and B. Bhattacharjee, 993 "BitTorrent is an Auction: Analyzing and Improving 994 BitTorrent's Incentives", SIGCOMM 2008, August 2008. 996 [PPLive] "PPLive", . 998 Appendix A. Acknowledgments 1000 We would also like to thank Haibin Song for substantial contributions 1001 to earlier versions of this document. We would also like to thank 1002 Reinaldo Penno, Alexey Melnikov, Rich Woundy, Ning Zong, Roni Even, 1003 David McDysan, Boerje Ohlman, Dirk Kutscher, Akbar Rahman, Xiao Zhu, 1004 Yunfei Zhang, and Jin Peng for contributions and general feedback. 1006 Authors' Addresses 1008 Yingjie Gu 1009 Huawei 1010 No. 101 Software Avenue 1011 Nanjing, Jiangsu Province 210012 1012 P.R.China 1014 Phone: +86-25-56624760 1015 Email: guyingjie@huawei.com 1017 David A. Bryan 1018 Polycom, Inc. 1020 Email: dbryan@ethernot.org 1022 Yang Richard Yang 1023 Yale University 1025 Email: yry@cs.yale.edu 1027 Richard Alimi 1028 Google 1030 Email: ralimi@google.com