idnits 2.17.1 draft-ietf-decade-reqs-03.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 (July 11, 2011) is 4673 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 Summary: 1 error (**), 0 flaws (~~), 2 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: January 12, 2012 Polycom, Inc. 6 Y. Yang 7 Yale University 8 R. Alimi 9 Google 10 July 11, 2011 12 DECADE Requirements 13 draft-ietf-decade-reqs-03 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 store and retrieve, 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). A user of DECADE as a complete architecture 28 would be guaranteed complete functionality. 30 Requirements Language 32 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 33 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 34 document are to be interpreted as described in [RFC2119]. 36 Status of this Memo 38 This Internet-Draft is submitted to IETF in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF), its areas, and its working groups. Note that 43 other groups may also distribute working documents as Internet- 44 Drafts. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 The list of current Internet-Drafts can be accessed at 52 http://www.ietf.org/ietf/1id-abstracts.txt. 54 The list of Internet-Draft Shadow Directories can be accessed at 55 http://www.ietf.org/shadow.html. 57 This Internet-Draft will expire on January 12, 2012. 59 Copyright Notice 61 Copyright (c) 2011 IETF Trust and the persons identified as the 62 document authors. All rights reserved. 64 This document is subject to BCP 78 and the IETF Trust's Legal 65 Provisions Relating to IETF Documents 66 (http://trustee.ietf.org/license-info) in effect on the date of 67 publication of this document. Please review these documents 68 carefully, as they describe your rights and restrictions with respect 69 to this document. Code Components extracted from this document must 70 include Simplified BSD License text as described in Section 4.e of 71 the Trust Legal Provisions and are provided without warranty as 72 described in the BSD License. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 77 2. Terminology and Concepts . . . . . . . . . . . . . . . . . . . 5 78 3. Requirements Structure . . . . . . . . . . . . . . . . . . . . 6 79 4. Protocol Requirements . . . . . . . . . . . . . . . . . . . . 7 80 4.1. Overall Protocol Requirements . . . . . . . . . . . . . . 7 81 4.1.1. Metadata and Cross-platform Access . . . . . . . . . . 7 82 4.1.2. Connectivity Concerns . . . . . . . . . . . . . . . . 7 83 4.1.2.1. NATs and Firewalls . . . . . . . . . . . . . . . . 7 84 4.1.2.2. Connections to Clients . . . . . . . . . . . . . . 8 85 4.1.3. Security . . . . . . . . . . . . . . . . . . . . . . . 8 86 4.1.3.1. Secure Transport . . . . . . . . . . . . . . . . . 8 87 4.1.4. Error and Failure Conditions . . . . . . . . . . . . . 8 88 4.1.4.1. Overload Condition . . . . . . . . . . . . . . . . 8 89 4.1.4.2. Insufficient Resources . . . . . . . . . . . . . . 8 90 4.1.4.3. Unavailable and Deleted Data . . . . . . . . . . . 9 91 4.1.4.4. Redirection . . . . . . . . . . . . . . . . . . . 9 92 4.2. Transfer and Latency Requirements . . . . . . . . . . . . 9 93 4.2.1. Low-Latency Access . . . . . . . . . . . . . . . . . . 9 94 4.2.2. Data Object Size . . . . . . . . . . . . . . . . . . . 10 95 4.2.3. Communication among DECADE Servers . . . . . . . . . . 10 96 4.3. Data Access Requirements . . . . . . . . . . . . . . . . . 11 97 4.3.1. Reading/Writing Own Storage . . . . . . . . . . . . . 11 98 4.3.2. Access by Other Users . . . . . . . . . . . . . . . . 11 99 4.3.3. Negotiable Data Transport Protocol . . . . . . . . . . 11 100 4.3.4. Separation of Data and Control Policies . . . . . . . 12 101 4.4. Data Management Requirements . . . . . . . . . . . . . . . 12 102 4.4.1. Agnostic of reliability . . . . . . . . . . . . . . . 12 103 4.4.2. Time-to-live for Written Data Objects . . . . . . . . 12 104 4.4.3. Offline Usage . . . . . . . . . . . . . . . . . . . . 13 105 4.5. Data Naming Requirements . . . . . . . . . . . . . . . . . 13 106 4.5.1. Unique Names . . . . . . . . . . . . . . . . . . . . . 13 107 4.6. Resource Control . . . . . . . . . . . . . . . . . . . . . 13 108 4.6.1. Multiple Applications . . . . . . . . . . . . . . . . 13 109 4.6.2. Per-Remote-Client, Per-Data Control . . . . . . . . . 14 110 4.6.3. Server Involvement . . . . . . . . . . . . . . . . . . 14 111 4.7. Authorization . . . . . . . . . . . . . . . . . . . . . . 15 112 4.7.1. Per-Remote-Client, Per-Data Read Access . . . . . . . 15 113 4.7.2. Per-User Write Access . . . . . . . . . . . . . . . . 15 114 4.7.3. Default Access Permissions . . . . . . . . . . . . . . 15 115 4.7.4. Authorization Checks . . . . . . . . . . . . . . . . . 15 116 4.7.5. Cryptographic Credentials . . . . . . . . . . . . . . 16 117 4.7.6. Server Involvement . . . . . . . . . . . . . . . . . . 16 118 4.7.7. Protocol Reuse . . . . . . . . . . . . . . . . . . . . 16 119 5. Storage Requirements . . . . . . . . . . . . . . . . . . . . . 16 120 5.1. Immutable Data . . . . . . . . . . . . . . . . . . . . . . 16 121 5.2. Explicit Deletion of Data . . . . . . . . . . . . . . . . 17 122 5.3. Multiple writing . . . . . . . . . . . . . . . . . . . . . 17 123 5.4. Multiple reading . . . . . . . . . . . . . . . . . . . . . 17 124 5.5. Reading before completely written . . . . . . . . . . . . 18 125 5.6. Hints concerning usage of written data . . . . . . . . . . 18 126 5.7. Writing model . . . . . . . . . . . . . . . . . . . . . . 18 127 5.8. Storage Status . . . . . . . . . . . . . . . . . . . . . . 18 128 6. Discovery Requirements . . . . . . . . . . . . . . . . . . . . 19 129 6.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 19 130 6.1.1. Locating DECADE Servers . . . . . . . . . . . . . . . 19 131 6.1.2. Support for Clients Behind NATs and Firewalls . . . . 19 132 6.1.3. Prefer Existing Protocols . . . . . . . . . . . . . . 20 133 7. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 20 134 7.1. Non-IAP Internal Protocols . . . . . . . . . . . . . . . . 20 135 7.2. Fairness . . . . . . . . . . . . . . . . . . . . . . . . . 20 136 7.3. Removal of Duplicate Data Objects . . . . . . . . . . . . 20 137 7.4. Gaming of the Resource Control Mechanism . . . . . . . . . 21 138 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 139 8.1. Authentication and Authorization . . . . . . . . . . . . . 21 140 8.2. Encrypted Data . . . . . . . . . . . . . . . . . . . . . . 21 141 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 142 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 143 10.1. Normative References . . . . . . . . . . . . . . . . . . . 22 144 10.2. Informative References . . . . . . . . . . . . . . . . . . 22 145 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 22 146 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 148 1. Introduction 150 The object of DECoupled Application Data Enroute (DECADE) is to 151 provide an open and standard in-network storage system for content 152 distribution applications, where data is typically broken in to one 153 or more chunks and then distributed. This may already include many 154 types of applications including P2P applications, IPTV (Internet 155 Protocol Television), and VoD (Video on Demand). (For a precise 156 definition of the applications targeted in DECADE, see the definition 157 for Target Application in Section 2.) Instead of always transferring 158 data directly from a source/owner client to a requesting client, the 159 source/owner client can write to and manage its content on its in- 160 network storage. The requesting client can get the address of the 161 in-network storage pertaining to the source/owner client and read 162 data from the storage. 164 This draft enumerates and explains the rationale behind SPECIFIC 165 requirements on the protocol design and on any data store 166 implementation that may be used to implement DECADE servers that 167 should be considered during the design and implementation of a DECADE 168 system. As such, it DOES NOT include general guiding principles. 169 General design considerations, explanation of the problem being 170 addressed, and enumeration of the types of applications to which 171 DECADE may be suited is not considered in this document. For general 172 information, please see the problem statement 173 [I-D.ietf-decade-problem-statement] and architecture drafts. 175 This document enumerates the requirements to enable target 176 applications to utilize in-network storage. In this context, using 177 storage resources includes not only basic capabilities such as 178 writing, reading, and managing data, but also controlling access for 179 particular remote clients with which it is sharing data. 180 Additionally, we also consider controlling the resources used by 181 remote clients when they access data as an integral part of utilizing 182 the network storage. 184 2. Terminology and Concepts 186 This document uses terms defined in 187 [I-D.ietf-decade-problem-statement]. In particular, IAP refers to 188 the In-network storage Access Protocol, which is the protocol used to 189 communicate between a DECADE client and DECADE server (in-network 190 storage) for access control and resource control. 192 This document also defines additional terminology: 194 Target Application: An application (typically installed at end-hosts) 195 with the ability to explicitly control usage of network and/or 196 storage resources to deliver content to a large number of users. 197 This includes scenarios where multiple applications or entities 198 cooperate, such as with P2P (peer-to-peer) / CDN (Content 199 Distribution Network) hybrid architectures. Such applications 200 distribute large amounts of content (e.g., a large file, or video 201 stream) by dividing the content into smaller blocks for more flexible 202 distribution (e.g., over multiple application-level paths). The 203 distributed content is typically immutable (though it may be 204 deleted). We use the term Target Application to refer to the type of 205 applications that are explicitly (but not exclusively) supported by 206 DECADE. 208 3. Requirements Structure 210 The DECADE protocol is intended to sit between Target Applications 211 and a back-end storage system. DECADE does not intend to develop yet 212 another storage system, but rather to create a protocol that enables 213 Target Applications to make use of storage within the network, 214 leaving specific storage system considerations to the implementation 215 of the DECADE servers as much as possible. For this reason, we have 216 divided the requirements into two primary categories: 218 o Protocol Requirements: Protocol requirements for Target 219 Applications to make use of in-network storage within their own 220 data dissemination schemes. Development of these requirements is 221 guided by a study of data access, search and management 222 capabilities used by Target Applications. These requirements may 223 be met by a new protocol to be defined within the DECADE Working 224 Group. 226 o Storage Requirements: Functional requirements necessary for the 227 back-end storage system employed by the DECADE server. 228 Development of these requirements is guided by a study of the data 229 access patterns used by Target Applications. These requirements 230 should be met by the underlying data transport used by DECADE. In 231 this document, we use "data transport" to refer to a protocol used 232 to read and write data from DECADE in-network storage. 234 Note that a third category also enumerates requirements on the 235 protocol used to discovery DECADE Servers. 237 It should also be made clear that the approach is to make DECADE a 238 simple protocol, while still enabling its usage within many Target 239 Applications. For this reason, and to further reinforce the 240 distinction between DECADE and a storage system, in some cases we 241 also highlight the non-requirements of the protocol. These non- 242 requirements are intended to capture behaviors that will NOT be 243 assumed to be needed by DECADE's Target Applications and hence not 244 present in the DECADE protocol. 246 Finally, some implementation considerations are provided, which while 247 not strictly requirements, are intended to provide guidance and 248 highlight potential points that need to be considered by the protocol 249 developers, and later by implementors. 251 4. Protocol Requirements 253 This section details the requirements of the DECADE IAP. 255 4.1. Overall Protocol Requirements 257 4.1.1. Metadata and Cross-platform Access 259 REQUIREMENT(S): If DECADE supports the ability to associate metadata 260 with data objects, the DECADE protocol(s) MUST transmit any 261 metadata using an operating system-independent and architecture- 262 independent standard format. 264 RATIONALE: If DECADE supports storing metadata (e.g., a description, 265 uploaded date, object size), a possible use for the metadata is 266 to help a DECADE client locate a desired data object. Data 267 objects may be written by DECADE clients running on various 268 platforms. To enable metadata to be readable regardless of its 269 source it must be transmitted to and from the DECADE server in a 270 standard format. 272 4.1.2. Connectivity Concerns 274 4.1.2.1. NATs and Firewalls 276 REQUIREMENT(S): DECADE SHOULD be usable across firewalls and NAT 277 (Network Address Translation) devices without requiring 278 additional network support (e.g., Application-level Gateways). 280 RATIONALE: Firewalls and NATs are widely used in the Internet today, 281 both in ISP (Internet Service Provider) and Enterprise networks 282 and by consumers. Deployment of DECADE must not require 283 modifications to such devices (beyond, perhaps, reconfiguration). 284 Note that this requirement applies to both any new protocol 285 developed by the DECADE Working Group and any data transport used 286 with DECADE. 288 4.1.2.2. Connections to Clients 290 REQUIREMENT(S): DECADE SHOULD require that network connections be 291 made from DECADE clients to DECADE servers (i.e., not from the 292 server to the DECADE client). 294 RATIONALE: Many household networks and operating systems have 295 firewalls and NATs configured by default to block incoming 296 connections. To ease deployment by avoiding configuration 297 changes and help mitigate security risks, DECADE should not 298 require clients to listen for any incoming network connections 299 (beyond what is required by any other already-deployed 300 application). 302 4.1.3. Security 304 4.1.3.1. Secure Transport 306 REQUIREMENT(S): DECADE MUST contain a mode in which all 307 communication between a DECADE client and server is over a secure 308 transport that provides confidentiality, integrity, and 309 authentication. 311 RATIONALE: Target Applications may wish to write sensitive data. To 312 satisfy this use case, DECADE must provide a mode in which all 313 communication between a DECADE client and server occurs over a 314 secure transport protocol (e.g., SSL/TLS). 316 4.1.4. Error and Failure Conditions 318 4.1.4.1. Overload Condition 320 REQUIREMENT(S): In-network storage, which is operating close to its 321 capacity limit (e.g., too busy servicing other requests), MUST be 322 able to reject requests and not be required to generate responses 323 to additional requests. 325 RATIONALE: Forcing the in-network storage to respond to requests 326 when operating close to its capacity can impair its ability to 327 service existing requests, and thus is permitted to avoid 328 generating responses to additional requests. 330 4.1.4.2. Insufficient Resources 331 REQUIREMENT(S): DECADE MUST support an error condition indicating to 332 a DECADE client that resources (e.g., storage space) were not 333 available to service a request (e.g., storage quota exceeded when 334 attempting to write data). 336 RATIONALE: The currently-used resource levels within the in-network 337 storage are not locally-discoverable, since the resources (disk, 338 network interfaces, etc) are not directly attached. In order to 339 allocate resources appropriately amongst remote clients, a client 340 must be able to determine when resource limits have been reached. 341 The client can then respond by explicitly freeing necessary 342 resources or waiting for such resources to be freed. 344 4.1.4.3. Unavailable and Deleted Data 346 REQUIREMENT(S): DECADE MUST support error conditions indicating that 347 (1) data was rejected from being written, (2) deleted, or (3) 348 marked unavailable by a storage provider. 350 RATIONALE: Storage providers may require the ability to (1) avoid 351 storing, (2) delete, or (3) quarantine certain data that has been 352 identified as illegal (or otherwise prohibited). DECADE does not 353 indicate how such data is identified, but applications using 354 DECADE should not break if a storage provider is obligated to 355 enforce such policies. Appropriate error conditions should be 356 indicated to applications. 358 4.1.4.4. Redirection 360 REQUIREMENT(S): DECADE SHOULD support the ability for a DECADE 361 server to redirect requests to another DECADE server. This may 362 be in response to either an error or failure condition, or to 363 support capabilities such as load balancing. 365 RATIONALE: A DECADE server may opt to redirect requests to another 366 server to support capabilities such as load balancing, or if the 367 implementation decides that another DECADE server is in a better 368 position to handle the request due to either its location in the 369 network, server status, or other consideration. 371 4.2. Transfer and Latency Requirements 373 4.2.1. Low-Latency Access 374 REQUIREMENT(S): DECADE SHOULD provide "low-latency" access for 375 application clients. DECADE MUST allow clients to specify at 376 least two classes of services for service: lowest possible 377 latency and latency non-critical. 379 RATIONALE: Some applications may have requirements on delivery time 380 (e.g., live streaming [PPLive]). The user experience may be 381 unsatisfactory if the use of in-network storage results in lower 382 performance than connecting directly to remote clients over a 383 low-speed, possibly congested uplink. Additionally, the overhead 384 required for control-plane operations in DECADE must not cause 385 the latency to be higher than for a low-speed, possibly congested 386 uplink. While it is impossible to make a guarantee that a system 387 using in-network storage will always outperform a system that 388 does not for every transfer, the overall performance of the 389 system should be improved compared with direct low-speed uplink 390 connections, even considering control overhead. 392 4.2.2. Data Object Size 394 REQUIREMENT(S): DECADE MUST allow for efficient data transfer of 395 small objects (e.g., 16KB) between a DECADE client and in-network 396 storage with minimal additional latency imposed by the protocol. 398 RATIONALE: Though Target Applications are frequently used to share 399 large amounts of data (e.g., continuous streams or large files), 400 the data itself is typically subdivided into smaller chunks that 401 are transferred between clients. Additionally, the small chunks 402 may have requirements on delivery time (e.g., in a live-streaming 403 application). DECADE must enable data to be efficiently 404 transferred amongst clients at this granularity. 406 4.2.3. Communication among DECADE Servers 408 REQUIREMENT(S): DECADE SHOULD support the ability for two in-network 409 storage elements in different administrative domains to write 410 and/or read data directly between each other (if authorized as 411 described in Section 4.7). If such a capability is supported, 412 this MAY be the same (or a subset or extension of) as the IAP 413 used by clients to access data. 415 RATIONALE: Allowing server-to-server communication can reduce 416 latency in some common scenarios. Consider a scenario when a 417 DECADE client is downloading data into its own storage from 418 another client's in-network storage. One possibility is for the 419 client to first download the data itself, and then upload it to 420 its own storage. However, this causes unnecessary latency and 421 network traffic. Allowing the data to be downloaded from the 422 remote in-network storage into the client's own in-network 423 storage can alleviate both. 425 4.3. Data Access Requirements 427 4.3.1. Reading/Writing Own Storage 429 REQUIREMENT(S): DECADE MUST support the ability for a DECADE client 430 to read data from and write data to its own in-network storage. 432 RATIONALE: Two basic capabilities for any storage system are reading 433 and writing data. A DECADE client can read data from and write 434 data to in-network storage space that it owns. 436 4.3.2. Access by Other Users 438 REQUIREMENT(S): DECADE MUST support the ability for a user to apply 439 access control policies to users other than itself for its 440 storage. The users with whom access is being shared can be under 441 a different administrative domain than the user who owns the in- 442 network storage. The authorized users may read from or write to 443 the user's storage. 445 RATIONALE: Endpoints in Target Applications may be located across 446 multiple ISPs under multiple administrative domains. Thus, to be 447 useful by Target Applications, DECADE allows a user to implement 448 access control policies for users that may or may not be known to 449 the user's storage provider. 451 4.3.3. Negotiable Data Transport Protocol 453 REQUIREMENT(S): DECADE MUST support the ability for a DECADE client 454 to negotiate with its in-network storage about which protocol it 455 can use to read data from and write data to its In-network 456 storage. DECADE MUST specify at least one mandatory protocol to 457 be supported by implementations; usage of a different protocol 458 may be selected via negotiation. 460 RATIONALE: Since typical data transport protocols (e.g., NFS and 461 WebDAV) already provide read and write operations for network 462 storage, it may not be necessary for DECADE to define such 463 operations in a new protocol. However, because of the particular 464 application requirements and deployment considerations, different 465 applications may support different protocols. Thus, a DECADE 466 client must be able to select an appropriate protocol also 467 supported by the in-network storage. This requirement also 468 follows as a result of the requirement of Separation of Control 469 and Data Operations (Section 4.3.4). 471 4.3.4. Separation of Data and Control Policies 473 REQUIREMENT(S): The DECADE IAP MUST only provide a minimal set of 474 core operations to support diverse policies implemented and 475 desired by Target Applications. 477 RATIONALE: Target Applications support many complex behaviors and 478 diverse policies to control and distribute data, such as (e.g., 479 search, index, setting permissions/passing authorization tokens). 480 Thus, to support such Target Applications, these behaviors must 481 be logically separated from the data transfer operations (e.g., 482 read, write). Some minimal overlap (for example obtaining 483 credentials needed to encrypt or authorize data transfer using 484 control operations) may be required to be directly specified by 485 DECADE. 487 4.4. Data Management Requirements 489 4.4.1. Agnostic of reliability 491 REQUIREMENT(S): DECADE SHOULD remain agnostic of reliability/ 492 fault-tolerance level offered by storage provider. 494 RATIONALE: Providers of a DECADE service may wish to offer varying 495 levels of service for different applications/users. However, a 496 single compliant DECADE client should be able to use multiple 497 DECADE services with differing levels of service. 499 4.4.2. Time-to-live for Written Data Objects 501 REQUIREMENT(S): DECADE MUST support the ability for a DECADE client 502 to indicate a time-to-live value (or expiration time) indicating 503 a length of time until particular data can be deleted by the in- 504 network storage element. 506 RATIONALE: Some data objects written by a DECADE client may be 507 usable only within a certain window of time, such as in live- 508 streaming P2P applications. Providing a time-to-live value for 509 data objects (e.g., at the time they are written) can reduce 510 management overhead by avoiding many 'delete' commands sent to 511 in-network storage. The in-network storage may still keep the 512 data in cache for bandwidth optimization. But this is guided by 513 the privacy policy of the DECADE provider. 515 4.4.3. Offline Usage 517 REQUIREMENT(S): DECADE MAY support the ability for a user to provide 518 authorized access to its in-network storage even if the user has 519 no DECADE applications actively running or connected to the 520 network. 522 RATIONALE: If an application desires, it can authorize remote 523 clients to access its storage even after the application exits or 524 network connectivity is lost. An example use case is mobile 525 scenarios, where a client can lose and regain network 526 connectivity very often. 528 4.5. Data Naming Requirements 530 4.5.1. Unique Names 532 REQUIREMENT(S): DECADE MUST use a naming scheme with an extremely 533 large namespace and mechanisms that ensure that the name of a 534 data object is statistically unlikely to be the same as the names 535 of all other data objects (globally) with different content. 536 DECADE SHOULD provide a mechanism (minimally rejection) to handle 537 the improbable case of a collision. 539 RATIONALE: When writing a data object, a DECADE Client should be 540 able to write it without being concerned over whether an object 541 of the same name already exists, unless the existing object 542 contains the exact same data. Note that it may be reasonable for 543 DECADE to satisfy this requirement probabilistically (e.g., using 544 a hashing mechanism). As a result, it is wise to provide a 545 collision handling mechanism, even if the probability of 546 collisions is extremely low. 548 4.6. Resource Control 550 4.6.1. Multiple Applications 552 REQUIREMENT(S): DECADE SHOULD support the ability for users to 553 define resource sharing policies for multiple applications 554 (DECADE clients) being run/managed by the user. 556 RATIONALE: A user may own in-network storage and share the in- 557 network storage resources amongst multiple applications. For 558 example, the user may run one or more video-on-demand 559 application(s) and a live-streaming application(s) which both 560 make use of the user's in-network storage. The applications may 561 be running on different machines and may not directly 562 communicate. Thus, DECADE should enable the user to determine 563 resource sharing policies between the applications. 565 One possibility is for a user to indicate the particular resource 566 sharing policies between applications out-of-band (not using a 567 standard protocol), but this requirement may manifest itself in 568 passing values over IAP to identify individual applications. 569 Such identifiers can be either user-generated or server-generated 570 and do not need to be registered by IANA. 572 4.6.2. Per-Remote-Client, Per-Data Control 574 REQUIREMENT(S): A DECADE client MUST be able to assign resource 575 policies (bandwidth share, storage quota, and network connection 576 quota) to individual remote clients for reading from and writing 577 particular data to its in-network storage within a particular 578 range of time. The DECADE server MUST enforce these constraints. 580 RATIONALE: Target Applications can rely on control of resources on a 581 per-remote-client or per-data basis. For example, application 582 policy may indicate that certain remote clients have a higher 583 bandwidth share for receiving data [LLSB08]. Additionally, 584 certain data (e.g., chunks) may be distributed with a higher 585 priority. As another example, when allowing a remote client to 586 write data to a user's in-network storage, the remote client may 587 be restricted to write only a certain amount of data. Since the 588 client may need to manage multiple clients accessing its data, it 589 should be able to indicate the time over which the granted 590 resources are usable. For example, an expiration time for the 591 access could be indicated to the server after which no resources 592 are granted (e.g., indicate error as access denied). 594 4.6.3. Server Involvement 596 REQUIREMENT(S): A DECADE client SHOULD be able to indicate to a 597 DECADE server, without itself contacting the server, resource 598 control policies for remote clients' requests. 600 RATIONALE: One important consideration for in-network storage 601 elements is scalability, since a single storage element may be 602 used to support many users. Many Target Applications use small 603 chunk sizes and frequent data exchanges. If such an application 604 employed resource control and contacted the in-network storage 605 element for each data exchange, this could present a scalability 606 challenge for the server as well as additional latency for 607 clients. 609 An alternative is to let requesting users obtain signed resource 610 control policies (in the form of a token) from the owning user, 611 and then users can then present the policy to the storage 612 directly. This can result in reduced messaging handled by the 613 in-network storage. 615 4.7. Authorization 617 4.7.1. Per-Remote-Client, Per-Data Read Access 619 REQUIREMENT(S): A DECADE Client MUST be able to control which 620 individual remote clients are authorized to read particular data 621 from its in-network storage. 623 RATIONALE: A Target Application can control certain application- 624 level policies by sending particular data (e.g., chunks) to 625 certain remote clients. It is important that remote clients not 626 be able to circumvent such decisions by arbitrarily reading any 627 data in in-network storage. 629 4.7.2. Per-User Write Access 631 REQUIREMENT(S): A DECADE Client MUST be able to control which 632 individual remote clients are authorized to write data into its 633 in-network storage. 635 RATIONALE: The space managed by a user in in-network storage can be 636 a limited resource. At the same time, it can be useful to allow 637 remote clients to write data directly to a user's in-network 638 storage. Thus, a DECADE client should be able to grant only 639 certain remote clients this privilege. 641 4.7.3. Default Access Permissions 643 REQUIREMENT(S): Unless read or write access is granted by a DECADE 644 Client to a remote client, the default access MUST be no access. 646 RATIONALE: The current leading proposal for an access control model 647 in DECADE is via token passing, resulting in a system with little 648 state on the server side. 650 4.7.4. Authorization Checks 652 REQUIREMENT(S): In-network storage MUST check the authorization of a 653 client before it executes a supplied request. The in-network 654 storage MAY use optimizations to avoid such authorization checks 655 as long as the enforced permissions are the same. 657 RATIONALE: Authorization granted by a DECADE client are meaningless 658 unless unauthorized requests are denied access. Thus, the in- 659 network storage element must verify the authorization of a 660 particular request before it is executed. 662 4.7.5. Cryptographic Credentials 664 REQUIREMENT(S): Access MUST be able to be granted using 665 cryptographic credentials. 667 RATIONALE: DECADE clients may be operating on hosts without constant 668 network connectivity or without a permanent attachment address 669 (e.g., mobile devices). To support access control with such 670 hosts, DECADE servers must support access control policies that 671 use cryptographic credentials, not simply by tying access to IP 672 addresses. 674 4.7.6. Server Involvement 676 REQUIREMENT(S): A DECADE client SHOULD be able to indicate, without 677 contacting the server itself, access control policies for remote 678 clients' requests. 680 RATIONALE: See discussion in Section 4.6.3. 682 4.7.7. Protocol Reuse 684 REQUIREMENT(S): If possible, DECADE SHOULD reuse existing protocol 685 and mechanisms for Authentication, Access, and Authorization 686 (AAA). 688 RATIONALE: If possible, reusing an existing AAA protocol/mechanism 689 will minimize the development required by applications, and will 690 maximize interoperability of the DECADE protocol with existing 691 infrastructure. 693 5. Storage Requirements 695 This section details the requirements of the underlying storage used 696 to support the DECADE IAP. 698 5.1. Immutable Data 699 REQUIREMENT(S): DECADE MUST provide the ability to manage data 700 objects that are immutable once they are written to storage. 702 RATIONALE: Immutable data objects are an important simplification in 703 DECADE. Reasonable consistency models for updating existing 704 objects would significantly complicate implementation (especially 705 if implementation chooses to replicate data across multiple 706 servers). If a user needs to update a resource, it can write a 707 new resource and then distribute the new resource instead of the 708 old one. 710 5.2. Explicit Deletion of Data 712 REQUIREMENT(S): DECADE MUST support the ability for a DECADE client 713 to explicitly delete data from its own in-network storage. 715 RATIONALE: A DECADE client may continually be writing data to its 716 in-network storage. Since there may be a limit (e.g., imposed by 717 the storage provider) to how much total storage can be used, some 718 data may need to be removed to make room for additional data. A 719 DECADE client should be able to explicitly remove particular 720 data. This may be implemented using existing protocols. 722 5.3. Multiple writing 724 REQUIREMENT(S): DECADE MUST NOT allow multiple simultaneous writers 725 for the same object. Implementations MUST raise an error to one 726 of the writers. 728 RATIONALE: This avoids data corruption in a simple way while 729 remaining efficient. Alternately, the DECADE server would need 730 to either manage locking, handle write collisions, or merge data, 731 all of which reduce efficiency and increase complexity. 733 5.4. Multiple reading 735 REQUIREMENT(S): DECADE MUST allow for multiple simultaneous readers 736 for an object. 738 RATIONALE: One characteristic of Target Applications is the ability 739 to upload an object to multiple clients. Thus, it is natural for 740 DECADE to allow multiple readers to read the content 741 concurrently. 743 5.5. Reading before completely written 745 REQUIREMENT(S): DECADE MAY allow readers to read from objects before 746 they have been completely written. 748 RATIONALE: Some Target Applications (in particular, P2P streaming) 749 can be sensitive to latency. A technique to reduce latency is to 750 remove store-and-forward delays for data objects (e.g., make the 751 object available before it is completely written). Appropriate 752 handling for error conditions (e.g., a disappearing writer) needs 753 to be specified. 755 5.6. Hints concerning usage of written data 757 REQUIREMENT(S): DECADE MAY allow writers of new objects to indicate 758 specific hints concerning how the objects are expected to be used 759 (e.g., access frequency or time to live). 761 RATIONALE: Different Target Applications may have different usage 762 patterns for objects written to in-network storage. For example, 763 a P2P live streaming application may indicate to a DECADE server 764 that the objects are expected to have a shore time-to-live, but 765 read frequently. The DECADE server may then opt to persist the 766 objects in memory instead of in disk. 768 5.7. Writing model 770 REQUIREMENT(S): DECADE storage MUST provide at least a writing model 771 (while writing an object) that appends data to data already 772 written. 774 RATIONALE: Depending on the object size (e.g., chunk size) used by a 775 Target Application, the application may need to send data to the 776 DECADE server in multiple packets. To keep implementation 777 simple, the DECADE must at least support the ability to write the 778 data sequentially in the order received. Implementations MAY 779 allow application to write data in an object out-of-order (but 780 MUST NOT overwrite ranges of the object that have already been 781 written). 783 5.8. Storage Status 785 REQUIREMENT(S): A DECADE client MUST be able to read current 786 resource usage (including list of written data objects), resource 787 quotas, and access permissions for its in-network storage. The 788 returned information MUST include resource usage resulting from 789 the client's own usage and usage by other clients that have been 790 authorized to read/write objects or open connections to that 791 client's storage. DECADE protocol(s) MUST support the ability 792 for a DECADE client to read aggregated resource usage information 793 (across all other clients to which it has authorized access), and 794 MAY support the ability to request this information for each 795 other authorized client. 797 RATIONALE: The resources used by a client are not directly-attached 798 (e.g., disk, network interface, etc). Thus, the client cannot 799 locally determine how such resources are being used. Before 800 storing and retrieving data, a client should be able to determine 801 which data is available (e.g., after an application restart). 802 Additionally, a client should be able to determine resource 803 availability to better allocate them to remote clients. Due to 804 scalability issues, it is not required that DECADE support 805 returning usage information broken down by each remote client 806 which has been authorized access, but this feature may be useful 807 in certain deployment scenarios. 809 6. Discovery Requirements 811 6.1. Requirements 813 6.1.1. Locating DECADE Servers 815 REQUIREMENT(S): The DECADE Discovery mechanism MUST allow a DECADE 816 Client to identify one or more DECADE Servers to which it is 817 authorized to read/write data and to which it may authorize other 818 DECADE Clients to read/write data, or fail if no such DECADE 819 Servers are available. 821 RATIONALE: A basic goal of DECADE is to allow DECADE Clients to 822 read/write data for access by other DECADE Clients or itself. 823 Executing the Discovery process should result in a DECADE Client 824 finding a DECADE Server that it can use for these purposes. It 825 is possible that no such DECADE Servers are available. Note that 826 even if a DECADE Client may not successfully locate a DECADE 827 Server that fits these criteria, it may still read/write data a 828 DECADE Server if authorized by another DECADE Client. 830 6.1.2. Support for Clients Behind NATs and Firewalls 832 REQUIREMENT(S): The Discovery mechanism MUST support DECADE Clients 833 operating behind NATs and Firewalls without requiring additional 834 network support (e.g., Application-level Gateways). 836 RATIONALE: NATs and Firewalls are prevalent in network deployments, 837 and it is common for Target Applications wishing to include a 838 DECADE Client to be deployed behind these devices. 840 6.1.3. Prefer Existing Protocols 842 REQUIREMENT(S): The DECADE Server discovery mechanism SHOULD prefer 843 to use existing mechanisms and protocols wherever possible. 845 RATIONALE: Existing protocols such as DNS and DHCP are widespread. 846 Using existing protocols, or combinations of the protocols that 847 have been specified in other contexts, is strictly preferred over 848 developing a new discovery protocol for DECADE. 850 7. Discussion 852 7.1. Non-IAP Internal Protocols 854 Sometimes, several logical in-network storage systems could be 855 deployed on the same physical network device. In this case, in- 856 network storages on the same physical network device can communicate 857 and transfer data through internal communication messages. However 858 in-network storages deployed on different physical network devices 859 SHOULD communicate with in-network storage Access Protocol (IAP). 861 7.2. Fairness 863 To provide fairness among users, the in-network storage provider 864 should assign resource (e.g., storage, bandwidth, connections) quota 865 for users. This can prevent a small number of clients from occupying 866 large amounts of resources on the in-network storage, while others 867 starve. 869 7.3. Removal of Duplicate Data Objects 871 There are actually two possible scenarios. The first is the case of 872 removing duplicates within one particular DECADE server (or logical 873 server). While not a requirement, as it does not impact the 874 protocol, a DECADE server may implement internal mechanisms to 875 monitor for duplicate objects and use internal mechanisms to prevent 876 duplication in internal storage. 878 The second scenario is removing duplicates across a distributed set 879 of DECADE servers. DECADE does not explicitly design for this, but 880 does offer a redirection mechanism (Section 4.1.4.4) that is one 881 primitive that may be used to support this feature in certain 882 deployment scenarios. 884 7.4. Gaming of the Resource Control Mechanism 886 The particular resource control policy communicated by a DECADE 887 protocol and enforced by the scheduling system of a DECADE 888 implementation may be open to certain gaming by clients. for example 889 by specifying many small peers to increase total throughput or 890 inciting overload conditions at a DECADE server. Identifying and 891 protecting against all such opportunities for gaming is outside the 892 scope of this document, but DECADE protocol(s) and implementations 893 SHOULD be aware that opportunities ti game the system may be 894 attempted. 896 8. Security Considerations 898 The security model is an important component of DECADE. It is 899 crucial for users to be able to manage and limit distribution of 900 content to only authorized parties, and the mechanism needs to work 901 on the general Internet which spans multiple administrative and 902 security domains. Previous sections have enumerated detailed 903 requirements, but this section discusses the overall approach and 904 other considerations that do not merit requirements. 906 8.1. Authentication and Authorization 908 DECADE only uses authentication when allowing a particular client to 909 access its own storage at a server. DECADE servers themselves do not 910 authenticate other clients which are reading/writing a client's own 911 storage. Instead, DECADE relies on clients to authenticate others to 912 access its storage, and then communicate the result of that 913 authentication to the DECADE server so that the DECADE server may 914 implement the necessary authorization checks. 916 8.2. Encrypted Data 918 DECADE Servers provide the ability to write raw data objects (subject 919 to any policies instituted by the owner/administrator if the DECADE 920 server, which are outside of the scope of this document). Thus, 921 DECADE clients may opt to encrypt data before it is written to the 922 DECADE Server. However, DECADE itself does not provide encryption of 923 data objects other than is provided by Section 4.1.3.1. 925 9. IANA Considerations 927 There are no IANA considerations with this document. 929 10. References 931 10.1. Normative References 933 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 934 Requirement Levels", BCP 14, RFC 2119, March 1997. 936 10.2. Informative References 938 [I-D.ietf-decade-problem-statement] 939 Song, H., Zong, N., Yang, Y., and R. Alimi, "DECoupled 940 Application Data Enroute (DECADE) Problem Statement", 941 draft-ietf-decade-problem-statement-03 (work in progress), 942 March 2011. 944 [LLSB08] Levin, D., LaCurts, K., Spring, N., and B. Bhattacharjee, 945 "BitTorrent is an Auction: Analyzing and Improving 946 BitTorrent's Incentives", SIGCOMM 2008, August 2008. 948 [PPLive] "PPLive", . 950 Appendix A. Acknowledgments 952 We would also like to thank Haibin Song for substantial contributions 953 to earlier versions of this document. We would also like to thank 954 Reinaldo Penno, Alexey Melnikov, Rich Woundy, Ning Zong, Roni Even, 955 David McDysan, Boerje Ohlman, Dirk Kutscher, Akbar Rahman, Xiao Zhu, 956 Yunfei Zhang, and Jin Peng for contributions and general feedback. 958 Authors' Addresses 960 Yingjie Gu 961 Huawei 962 No. 101 Software Avenue 963 Nanjing, Jiangsu Province 210012 964 P.R.China 966 Phone: +86-25-56624760 967 Email: guyingjie@huawei.com 969 David A. Bryan 970 Polycom, Inc. 972 Email: dbryan@ethernot.org 973 Yang Richard Yang 974 Yale University 976 Email: yry@cs.yale.edu 978 Richard Alimi 979 Google 981 Email: ralimi@google.com