DECADE Y. Gu Internet-Draft Huawei Intended status: Informational D. Bryan Expires: September 13, 2012 Polycom, Inc. Y. Yang Yale University R. Alimi Google March 12, 2012 DECADE Requirements draft-ietf-decade-reqs-06 Abstract The target of the DECoupled Application Data Enroute (DECADE) system is to provide an open and standard in-network storage system for applications, primarily P2P (peer-to-peer) applications, to store, retrieve and manage their data. This draft enumerates and explains requirements, not only for storage and retrieval, but also for data management, access control and resource control, that should be considered during the design and implementation of a DECADE- compatible system. These are requirements on the entire system; some of the requirements may eventually be implemented by an existing protocol with/without some extensions (e.g., a protocol used to read and write data from the storage system). The requirements in this document are intended to ensure that a DECADE-compatible system architecture includes all of the desired functionality for intended applications. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months Gu, et al. Expires September 13, 2012 [Page 1] Internet-Draft DECADE Requirements March 2012 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 13, 2012. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Gu, et al. Expires September 13, 2012 [Page 2] Internet-Draft DECADE Requirements March 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology and Concepts . . . . . . . . . . . . . . . . . . . 6 3. Requirements Structure . . . . . . . . . . . . . . . . . . . . 7 4. Protocol Requirements . . . . . . . . . . . . . . . . . . . . 7 4.1. Overall Protocol Requirements . . . . . . . . . . . . . . 7 4.1.1. Connectivity Concerns . . . . . . . . . . . . . . . . 7 4.1.1.1. NATs and Firewalls . . . . . . . . . . . . . . . . 8 4.1.1.2. Connections to Clients . . . . . . . . . . . . . . 8 4.1.2. Security . . . . . . . . . . . . . . . . . . . . . . . 8 4.1.2.1. Secure Transport . . . . . . . . . . . . . . . . . 8 4.1.2.2. Gaming Prevention . . . . . . . . . . . . . . . . 8 4.1.3. Error and Failure Conditions . . . . . . . . . . . . . 9 4.1.3.1. Overload Condition . . . . . . . . . . . . . . . . 9 4.1.3.2. Insufficient Resources . . . . . . . . . . . . . . 9 4.1.3.3. Unavailable and Deleted Data . . . . . . . . . . . 10 4.1.3.4. Insufficient Permissions . . . . . . . . . . . . . 10 4.1.3.5. Redirection . . . . . . . . . . . . . . . . . . . 10 4.2. Transfer Requirements . . . . . . . . . . . . . . . . . . 11 4.2.1. Data Object Size . . . . . . . . . . . . . . . . . . . 11 4.3. Data Access Requirements . . . . . . . . . . . . . . . . . 11 4.3.1. Reading/Writing Own Storage . . . . . . . . . . . . . 11 4.3.2. Access by Remote Clients . . . . . . . . . . . . . . . 11 4.3.3. Negotiable Data Transport Protocol . . . . . . . . . . 12 4.3.4. Separation of Data and Control Policies . . . . . . . 12 4.4. Data Management Requirements . . . . . . . . . . . . . . . 12 4.4.1. Agnostic of reliability . . . . . . . . . . . . . . . 12 4.4.2. Data Object Attributes . . . . . . . . . . . . . . . . 13 4.4.3. Time-to-live for Written Data Objects . . . . . . . . 13 4.4.4. Application-defined Properties and Metadata . . . . . 13 4.4.5. Offline Usage . . . . . . . . . . . . . . . . . . . . 14 4.5. Data Naming Requirements . . . . . . . . . . . . . . . . . 14 4.5.1. Unique Names . . . . . . . . . . . . . . . . . . . . . 14 4.6. Resource Control . . . . . . . . . . . . . . . . . . . . . 15 4.6.1. Multiple Applications . . . . . . . . . . . . . . . . 15 4.6.2. Per-Remote-Client, Per-Data Control . . . . . . . . . 15 4.6.3. Resource Control Set . . . . . . . . . . . . . . . . . 16 4.6.4. Server Involvement . . . . . . . . . . . . . . . . . . 16 4.7. Authorization . . . . . . . . . . . . . . . . . . . . . . 16 4.7.1. Per-Remote-Client, Per-Data Read Access . . . . . . . 16 4.7.2. Per-User Write Access . . . . . . . . . . . . . . . . 17 4.7.3. Default Access Permissions . . . . . . . . . . . . . . 17 4.7.4. Authorization Checks . . . . . . . . . . . . . . . . . 17 4.7.5. Cryptographic Credentials . . . . . . . . . . . . . . 17 4.7.6. Server Involvement . . . . . . . . . . . . . . . . . . 18 4.7.7. Protocol Reuse . . . . . . . . . . . . . . . . . . . . 18 5. Storage Requirements . . . . . . . . . . . . . . . . . . . . . 18 Gu, et al. Expires September 13, 2012 [Page 3] Internet-Draft DECADE Requirements March 2012 5.1. Immutable Data . . . . . . . . . . . . . . . . . . . . . . 18 5.2. Explicit Deletion of Data . . . . . . . . . . . . . . . . 19 5.3. Multiple writing . . . . . . . . . . . . . . . . . . . . . 19 5.4. Multiple reading . . . . . . . . . . . . . . . . . . . . . 19 5.5. Reading before completely written . . . . . . . . . . . . 19 5.6. Writing model . . . . . . . . . . . . . . . . . . . . . . 20 5.7. Storage Status . . . . . . . . . . . . . . . . . . . . . . 20 6. Discovery Requirements . . . . . . . . . . . . . . . . . . . . 21 6.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 21 6.1.1. Support for Clients Behind NATs and Firewalls . . . . 21 6.1.2. Prefer Existing Protocols . . . . . . . . . . . . . . 21 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 7.1. Authentication and Authorization . . . . . . . . . . . . . 21 7.2. Encrypted Data . . . . . . . . . . . . . . . . . . . . . . 22 7.3. Protection against Gaming . . . . . . . . . . . . . . . . 22 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 9.1. Normative References . . . . . . . . . . . . . . . . . . . 22 9.2. Informative References . . . . . . . . . . . . . . . . . . 22 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 Gu, et al. Expires September 13, 2012 [Page 4] Internet-Draft DECADE Requirements March 2012 1. Introduction The object of the DECoupled Application Data Enroute (DECADE) system is to provide an open and standard in-network storage for content distribution applications, where data is typically broken into one or more chunks and then distributed. This may already include many types of applications including P2P applications, IPTV (Internet Protocol Television), and VoD (Video on Demand). (For a precise definition of the applications targeted in DECADE system, see the definition for Target Application in Section 2.) Instead of always transferring data directly from a source/owner client to a requesting client, the source/owner client can write to and manage its content on its in-network storage. The requesting client can get the address of the in-network storage pertaining to the source/owner client and read data from the storage. This draft enumerates and explains the rationale behind specific requirements on the protocol design and on any data store implementation that may be used to implement DECADE servers that should be considered during the design and implementation of a DECADE-compatible system. As such, it does not include general guiding principles. General design considerations, explanation of the problem being addressed, and enumeration of the types of applications to which a DECADE-compatible system may be suited is not considered in this document. For general information, please see [I-D.ietf-decade-problem-statement] and [I-D.ietf-decade-arch]. This document enumerates the requirements to enable target applications to utilize in-network storage. In this context, using storage resources includes not only basic capabilities such as writing, reading, and managing data, but also controlling access for particular remote clients with which it is sharing data. Additionally, we also consider controlling the resources used by remote clients when they access data as an integral part of utilizing the network storage. This document discusses requirements pertaining to DECADE-compatible protocol(s). In certain deployments, several logical in-network storage systems could be deployed (e.g., within the same administrative domain). These in-network storage systems can communicate and transfer data through internal or non-standard communication messages that are outside of the scope of these requirements, but they should use DECADE-compatible protocol(s) when communicating with other DECADE-compatible in-network storage systems. Gu, et al. Expires September 13, 2012 [Page 5] Internet-Draft DECADE Requirements March 2012 2. Terminology and Concepts This document uses the term 'In-network storage' which is defined in [I-D.ietf-decade-problem-statement]. This document also defines additional terminology: Target Application: An application (typically installed at end-hosts) with the ability to explicitly control usage of network and/or storage resources to deliver content to a large number of users. This includes scenarios where multiple applications or entities cooperate, such as with P2P, CDN, and hybrid P2P/CDN architectures. Such applications distribute large amounts of content (e.g., a large file, or video stream) by dividing the content into smaller blocks for more flexible distribution (e.g., over multiple application-level paths). The distributed content is immutable (though it may be deleted and replaced). We use the term Target Application to refer to the type of applications that are explicitly (but not exclusively) supported by DECADE system. DECADE-compatible server: A physical entity that can control and manage in-network storage or a logical control and management component on in-network storage. DECADE-compatible client: An interface for target applications to make use of in-network storage in DECADE system. DECADE client is usually a software hosted on a end device, such as a PC or laptop. A DECADE-compatible client be employed by a target applications to communicate with DECADE server to make use of in-network storage. DECADE-compatible protocol: A protocol between a DECADE-compatible client and a DECADE-compatible server. In this document, a DECADE- compatible protocol represents the protocols, both existing and potential new protocols, that can be used by a DECADE-compatible client and DECADE-compatible server to communicate with each other. DECADE service provider: the provider who provides DECADE service to a DECADE-compatible client. DECADE service provider can be an in- network storage provider, or service provider who serve users of DECADE-compatible clients by renting or purchasing in-network storage from in-network storage provider. DECADE-compatible system: a system which is composed of DECADE- compatible clients, DECADE-compatible servers and in-network storage. A DECADE-compatible protocol is used for communication between DECADE-compatible clients and DECADE-compatible servers. A DECADE- compatible system MUST obey all the requirements defined in this document. Gu, et al. Expires September 13, 2012 [Page 6] Internet-Draft DECADE Requirements March 2012 3. Requirements Structure A DECADE-compatible protocol is intended to sit between Target Applications and a storage system. This document does not intend to develop yet another storage system or a new protocol, but rather to explore the requirements for the DECADE protocols, either existing ones or a potential new one, and storage system to enable Target Applications to make use of storage within the network, leaving specific storage system considerations to the implementation of the storage servers as much as possible. For this reason, we have divided the requirements into two primary categories: o Protocol Requirements: Protocol requirements for Target Applications to make use of in-network storage within their own data dissemination schemes. Development of these requirements is guided by a study of data access, search and management capabilities used by Target Applications. These requirements may be met by a combination of existing protocols and new protocols. o Storage Requirements: Functional requirements necessary for the back-end storage system employed by the DECADE server. Development of these requirements is guided by a study of the data access patterns used by Target Applications. These requirements should be met by the underlying data transport used by DECADE system. In this document, we use "data transport" to refer to a protocol used to read and write data from in-network storage. This specification discusses the requirements of functionality implemented with a storage system and within applications, to permit interoperable communications concerning the manipulation of stored content. 4. Protocol Requirements This section details the requirements of DECADE-compatible protocol(s) that can be used in a DECADE-compatible system implementation. The DECADE protocols can be existing protocols, as long as they satisfy the requirements specified in this document, or a new protocol which must obey all the requirements too. 4.1. Overall Protocol Requirements 4.1.1. Connectivity Concerns Gu, et al. Expires September 13, 2012 [Page 7] Internet-Draft DECADE Requirements March 2012 4.1.1.1. NATs and Firewalls REQUIREMENT(S): DECADE-compatible protocol(s) MUST be usable across firewalls and NAT (Network Address Translation) devices. DECADE protocol MUST NOT pass literal IP addresses in messages. RATIONALE: Firewalls and NATs are widely used in the Internet today, both in ISP (Internet Service Provider) and Enterprise networks and by consumers. Deployment of a DECADE-compatible system must not require modifications to such devices (beyond, perhaps, reconfiguration). This requirement applies to both potential new protocol that may be developed by the DECADE Working Group and any data transport used with DECADE protocol. 4.1.1.2. Connections to Clients REQUIREMENT(S): Network connections between DECADE-compatible client and DECADE-compatible server MUST be initiated by the client (i.e., the server must not initiate a connection with the client). RATIONALE: Many household networks and operating systems have firewalls and NATs configured by default to block incoming connections. To ease deployment by avoiding configuration changes and help mitigate security risks, a DECADE-compatible client must not be required to listen for any incoming network connections (beyond what is required by any other already- deployed application). 4.1.2. Security 4.1.2.1. Secure Transport REQUIREMENT(S): A secure transport MUST be implemented for all communications between a DECADE-compatible client and DECADE- compatible server. RATIONALE: Target Applications may wish to write sensitive data. To satisfy this use case, the communication between a DECADE- compatible client and DECADE-compatible server must be transported over a secure transport protocol (e.g., SSL/TLS). 4.1.2.2. Gaming Prevention Gu, et al. Expires September 13, 2012 [Page 8] Internet-Draft DECADE Requirements March 2012 REQUIREMENT(S): A DECADE-compatible server MUST be permitted to reject suspicious requests and not be required to generate responses (e.g., if a client's rate of requests exceeds a pre- defined threshold). RATIONALE: Malicious clients may attempt to attack a DECADE- compatible server by specifying many chunks to increase total throughput or inciting overload conditions. A DECADE-compatible server is permitted to reject or ignore requests that are deemed suspicious according to policies set by its DECADE service provider. 4.1.3. Error and Failure Conditions 4.1.3.1. Overload Condition REQUIREMENT(S): A DECADE-compatible server, which is operating close to its capacity limit (e.g., too busy servicing other requests), MUST be permitted to reject requests and not be required to generate response to additional requests. A DECADE-compatible server MUST also be permitted to redirect requests (see Section 4.1.3.5) as a load- shedding technique. RATIONALE: Forcing a DECADE-compatible server to respond to requests when operating close to its capacity can impair its ability to service existing requests, and thus is permitted to avoid generating response to additional requests. 4.1.3.2. Insufficient Resources REQUIREMENT(S): A DECADE-compatible server SHOULD be able to provide an error condition indicating to a DECADE-compatible client that resources (e.g., storage space) were not available to service a request (e.g., storage quota exceeded when attempting to write data). RATIONALE: The currently-used resource levels within the in-network storage may not be locally-discoverable. In order to allocate resources appropriately amongst remote clients, a DECADE- compatible client must be able to determine when resource limits have been reached. The DECADE-compatible client can then respond by explicitly freeing necessary resources or waiting for such resources to be freed. EXCEPTION: While a DECADE-compatible server is in the situation that is described in Section 4.1.2.2 or Section 4.1.3.1, it need not to respond with error condition. Gu, et al. Expires September 13, 2012 [Page 9] Internet-Draft DECADE Requirements March 2012 4.1.3.3. Unavailable and Deleted Data REQUIREMENT(S): A DECADE-compatible server SHOULD be able to provide error conditions indicating that (1) data was rejected from being written, (2) deleted, or (3) marked unavailable by a storage provider. RATIONALE: DECADE service providers may require the ability to (1) avoid storing, (2) delete, or (3) quarantine certain data that has been identified as illegal (or otherwise prohibited). It is not specified how such data is identified, but applications employing DECADE-compatible servers should not break if a storage provider is obligated to enforce such policies. Appropriate error conditions should be indicated to applications. EXCEPTION: A DECADE-compatible server should be able to configured as not respond to any request to access unavailable or deleted data on the in- network storage, for example, for security reasons. 4.1.3.4. Insufficient Permissions REQUIREMENT(S): A DECADE-compatible server MUST be able to provide error conditions indicating that the requesting client does not have sufficient permissions to access requested data objects. RATIONALE: DECADE-compatible clients may request objects to which they do not have sufficient access permissions, and DECADE- compatible servers must be able to signal that this has occurred. Access permissions may be insufficient due to a combination of the credentials presented by a client as well as additional policies defined by the storage provider. 4.1.3.5. Redirection REQUIREMENT(S): A DECADE-compatible server SHOULD be able to redirect requests to another DECADE-compatible server. This may either be in response to an error, failure, or overload condition, or to support capabilities such as load balancing. RATIONALE: A DECADE-compatible server may opt to redirect requests to another server to support capabilities such as load balancing, or if the implementation decides that another DECADE-compatible server is in a better position to handle the request due to either its location in the network, server status, or other consideration. Gu, et al. Expires September 13, 2012 [Page 10] Internet-Draft DECADE Requirements March 2012 EXCEPTION: A DECADE-compatible server can be configured by its service provider to support or not support redirection functionality. 4.2. Transfer Requirements 4.2.1. Data Object Size REQUIREMENT(S): DECADE-compatible protocol(s) MUST allow for efficient data transfer of small objects (e.g., 16KB) between a DECADE-compatible client and in-network storage with minimal additional latency imposed by the protocol(s). RATIONALE: Though Target Applications are frequently used to share large amounts of data (e.g., continuous streams or large files), the data itself is typically subdivided into smaller chunks that are transferred between clients. Additionally, clients may be sensitive to the delivery time of chunks (e.g., in a live- streaming application). DECADE-compatible protocol(s) must enable data to be efficiently transferred amongst DECADE- compatible clients at this granularity. 4.3. Data Access Requirements 4.3.1. Reading/Writing Own Storage REQUIREMENT(S): DECADE-compatible protocol(s) MUST enable a DECADE- compatible client to read data from and write data to its own in- network storage. RATIONALE: Two basic capabilities for any storage system are reading and writing data. A DECADE-compatible client can read data from and write data to in-network storage space that it owns. 4.3.2. Access by Remote Clients REQUIREMENT(S): A DECADE-compatible client MUST be able to apply access control policies to remote DECADE-compatible clients other than itself for its storage. The remote DECADE-compatible clients with whom access is being shared can be under a different administrative domain than the DECADE-compatible client who owns the in-network storage. RATIONALE: Endpoints in Target Applications may be located across multiple ISPs under multiple administrative domains. Thus, to be useful by Target Applications, a DECADE-compatible client must be able to specify access control policies for remote DECADE- compatible clients that may or may not be known to the client's Gu, et al. Expires September 13, 2012 [Page 11] Internet-Draft DECADE Requirements March 2012 own DECADE service provider. 4.3.3. Negotiable Data Transport Protocol REQUIREMENT(S): DECADE-compatible client MUST be able to negotiate with DECADE server about which protocol it can use to read data from and write data to its in-network storage. DECADE system MUST specify at least one mandatory protocol to be supported by implementations; usage of a different protocol may be selected via negotiation. RATIONALE: Since typical data transport protocols (e.g., NFS and WebDAV) already provide read and write operations for network storage, it may not be necessary to define such operations in a new DECADE protocol. However, because of the particular application requirements and deployment considerations, different applications may support different protocols. Thus, a DECADE client must be able to select an appropriate protocol also supported by the in-network storage. This requirement also follows as a result of the requirement of Separation of Control and Data Operations (Section 4.3.4). 4.3.4. Separation of Data and Control Policies REQUIREMENT(S): DECADE-compatible protocol(s) MUST provide a minimal set of core operations to support diverse policies implemented and desired by Target Applications, and MAY provide additional operations. RATIONALE: Target Applications support many complex behaviors and diverse policies to control and distribute data, such as (e.g., search, index, setting permissions/passing authorization tokens). Thus, to support such Target Applications, these behaviors must be logically separated from the data transfer operations (e.g., read, write). Some minimal overlap (for example obtaining credentials needed to encrypt or authorize data transfer using control operations) is required to be supported by DECADE- compatible protocol(s). 4.4. Data Management Requirements 4.4.1. Agnostic of reliability REQUIREMENT(S): DECADE-compatible protocol(s) MUST remain agnostic of reliability/ fault-tolerance level offered by DECADE service provider. Gu, et al. Expires September 13, 2012 [Page 12] Internet-Draft DECADE Requirements March 2012 RATIONALE: Providers of a DECADE service may wish to offer varying levels of service for different applications/users. However, a single DECADE-compatible client must be able to use multiple DECADE services with differing levels of service. 4.4.2. Data Object Attributes REQUIREMENT(S): DECADE-compatible protocol(s) MUST support the ability to associate attributes with data objects with a scope local to a DECADE-compatible server, and for DECADE-compatible clients to query these attributes. DECADE-compatible protocol(s) MUST transmit any attributes using an operating system- independent and architecture-independent standard format. If there is a need to design any DECADE protocols, they MUST be designed such that new attributes can be added by later protocol revisions or extensions. RATIONALE: A DECADE-compatible client can associate attributes (e.g., a time-to- live, creation timestamp, or object size) with a data object. These attributes are local to a data object stored by a particular DECADE-compatible server, and are thus not applied to any DECADE-compatible server or client to which the data object is copied. These attributes may be used as hints to the storage system, internal optimizations, or as additional information query-able by DECADE-compatible clients. 4.4.3. Time-to-live for Written Data Objects REQUIREMENT(S): A DECADE-compatible client MUST be able to indicate a time-to- live value (or expiration time) indicating a length of time until particular data can be deleted by a DECADE-compatible server. RATIONALE: Some data objects written by a DECADE-compatible client may be usable only within a certain window of time, such as in live- streaming P2P applications. Providing a time-to-live value for data objects (e.g., at the time they are written) can reduce management overhead by avoiding many 'delete' commands sent to DECADE-compatible server. The in-network storage may still keep the data in cache for bandwidth optimization. But this is guided by the privacy policy of the DECADE service provider. 4.4.4. Application-defined Properties and Metadata Gu, et al. Expires September 13, 2012 [Page 13] Internet-Draft DECADE Requirements March 2012 REQUIREMENT(S): DECADE-compatible clients and DECADE-compatible servers MUST NOT be able to associate Application-defined properties (metadata) with data objects beyond what is provided by Section 4.4.2. RATIONALE: Associating key-value pairs that are defined by Target Applications with data objects introduces substantial complexity to the protocol(s). If Target Applications wish to associate additional metadata with a data object, possible alternatives include (1) managing such metadata within the Target Application itself, (2) storing metadata inside of the data object, or (3) storing metadata in a different data object at the DECADE- compatible server. 4.4.5. Offline Usage REQUIREMENT(S): A DECADE-compatible client MAY provide authorized access from remote clients to its in-network storage even if the DECADE client is actively running or connected to a DECADE- compatible server. RATIONALE: If an application desires, it can authorize remote clients to access its storage even after the application exits or network connectivity is lost. An example use case is mobile scenarios, where a client can lose and regain network connectivity very often. 4.5. Data Naming Requirements 4.5.1. Unique Names REQUIREMENT(S): DECADE-compatible protocol(s) MUST support a data object naming scheme that ensures a high probability of uniqueness and supports the operation of DECADE-compatible servers under diverse administrative domains with no coordination. DECADE-compatible server SHOULD be able to respond to DECADE-compatible client with error condition indicating the name of the object conflicts with other object. RATIONALE: When writing a data object, a DECADE-compatible Client should be able to write it without being concerned over whether an object of the same name already exists, unless the existing object contains the exact same data. Although the intention is to avoid name collision, it's not absolutely zero possibility. As a result, it is required to provide a collision handling mechanism. Gu, et al. Expires September 13, 2012 [Page 14] Internet-Draft DECADE Requirements March 2012 EXCEPTION: While a DECADE-compatible server is in situations described in Section 4.1.2.2 or Section 4.1.3.1, it need not to generate a response to the client. 4.6. Resource Control 4.6.1. Multiple Applications REQUIREMENT(S): A DECADE-compatible client MUST be able to indicate to a DECADE-compatible server about resource sharing policies for multiple target applications being run/managed by the same user. RATIONALE: A user may own in-network storage and share the in- network storage resources amongst multiple target applications. For example, the user may run one or more video-on-demand application(s) and a live-streaming application(s) which both make use of the user's in-network storage. The applications may be running on different machines and may not directly communicate. Thus, user should be able to determine resource sharing policies between the applications. One possibility is for a user to indicate the particular resource sharing policies between applications out-of-band (not using a standard protocol), but this requirement may manifest itself in passing values within DECADE-compatible protocol(s) to identify individual applications. Such identifiers can be either user- generated or server-generated and do not need to be registered by IANA. 4.6.2. Per-Remote-Client, Per-Data Control REQUIREMENT(S): A DECADE-compatible client MUST be able to assign resource policies (bandwidth share, storage quota, and network connection quota) to individual remote clients for reading from and writing particular data to its in-network storage within a particular range of time. RATIONALE: Target Applications can rely on control of resources on a per-remote-client or per-data basis. For example, application policy may indicate that certain remote clients have a higher bandwidth share for receiving data [LLSB08]. Additionally, bandwidth share for receiving data [LLSB08]. Additionally, certain data (e.g., chunks) may be distributed with a higher priority. As another example, when allowing a remote client to write data to a user's in-network storage, the remote client may be restricted to write less than 100MB of data in total. Since the client may need to manage multiple clients accessing its data, it should be able to indicate the time over which the Gu, et al. Expires September 13, 2012 [Page 15] Internet-Draft DECADE Requirements March 2012 granted resources are usable. For example, an expiration time for the access could be indicated to the DECADE-compatible server after which no resources are granted (e.g., indicate error as access denied). 4.6.3. Resource Control Set REQUIREMENT(S): DECADE-compatible protocol(s) MUST define a minimum set of resource control methods, and MAY add additional set of resource control methods. RATIONALE: The minimum set of resource control methods need to include the most common resource control methods. Implementors can add proprietary set of resource control methods in their own implementation. 4.6.4. Server Involvement REQUIREMENT(S): A DECADE-compatible client MUST be able to indicate to a DECADE-compatible server, without itself contacting the server, resource control policies for remote clients' requests. A DECADE-compatible server MUST be able to authenticate the resource control policies in this situation. RATIONALE: One important consideration for a DECADE-compatible server is scalability, since a single storage element may be used to support many users. Many Target Applications use small chunk sizes and frequent data exchanges. If such an application employed resource control and contacted the DECADE-compatible server for each data exchange, this could present a scalability challenge for the server as well as additional latency for clients. The preferred way is to let requesting clients obtain signed resource control policies (in the form of a token) from the owning client, and then requesting clients can present the policy to a DECADE-compatible server directly. This can result in reduced messaging handled by the DECADE-compatible server. 4.7. Authorization 4.7.1. Per-Remote-Client, Per-Data Read Access REQUIREMENT(S): A DECADE-compatible Client MUST be able to control which individual remote clients are authorized to read particular data from its in-network storage. Gu, et al. Expires September 13, 2012 [Page 16] Internet-Draft DECADE Requirements March 2012 RATIONALE: A Target Application can control certain application- level policies by sending particular data (e.g., chunks) to certain remote clients. 4.7.2. Per-User Write Access REQUIREMENT(S): A DECADE-compatible Client MUST be able to control which individual remote clients are authorized to write data into its in-network storage. RATIONALE: The space managed by a user in in-network storage can be a limited resource. At the same time, it can be useful to allow remote clients to write data directly to a user's in-network storage. Thus, a DECADE-compatible client should be able to grant only certain remote clients this privilege. 4.7.3. Default Access Permissions REQUIREMENT(S): Unless read or write access is granted by a DECADE Client to a remote client, the default access MUST be no access. RATIONALE: The current leading proposal for an access control model in DECADE working group is via token passing, resulting in a system with little state on the server side. 4.7.4. Authorization Checks REQUIREMENT(S): A DECADE-compatible server MUST check the authorization of a client before it executes a supplied request. RATIONALE: The data stored at a DECADE-compatible server is assumed to be private, and thus not accessible to a DECADE-enabled client unless it is explicitly granted permission. 4.7.5. Cryptographic Credentials REQUIREMENT(S): Access MUST be able to be granted using cryptographic credentials. RATIONALE: DECADE-compatible clients may be operating on hosts without constant network connectivity or without a permanent attachment address (e.g., mobile devices). To support access control with such hosts, DECADE-compatible servers must support access control policies that use cryptographic credentials, not simply by tying access to IP addresses. Gu, et al. Expires September 13, 2012 [Page 17] Internet-Draft DECADE Requirements March 2012 4.7.6. Server Involvement REQUIREMENT(S): A DECADE-compatible client MUST be able to indicate, without contacting the server itself, access control policies for remote clients' requests. DECADE-compatible server MUST be able to authenticate the access control policies in this situation. RATIONALE: See discussion in Section 4.6.4. 4.7.7. Protocol Reuse REQUIREMENT(S): DECADE SHOULD reuse existing protocol and mechanisms for Authentication, Access, and Authorization (AAA). No new AAA protocol and mechanism are going to be defined unless there is explicit proof that existing protocol and mechanisms are not applicable. RATIONALE: If possible, reusing an existing AAA protocol/mechanism will minimize the development required by applications, and will maximize interoperability of the DECADE-compatible protocol(s) with existing infrastructure. 5. Storage Requirements This section details the requirements of the underlying storage used to support DECADE-compatible protocol(s). 5.1. Immutable Data REQUIREMENT(S): The data objects MUST be immutable once they are written to storage. RATIONALE: Immutable data objects are an important simplification in DECADE-compatible system. Reasonable consistency models for updating existing objects would significantly complicate implementation (especially if implementation chooses to replicate data across multiple servers). If the content owners have to modify the written data objects, there are many ways to do so. First, they can use different data names for different object versions. Secondly, they can split single monolithic files into fragments, so that new fragment versions could be substituted later (e.g. corrections or updated advertising) via a play list. Gu, et al. Expires September 13, 2012 [Page 18] Internet-Draft DECADE Requirements March 2012 5.2. Explicit Deletion of Data REQUIREMENT(S): A DECADE-compatible client MUST be able to explicitly delete data from its own in-network storage. RATIONALE: A DECADE-compatible client may continually be writing data to its in-network storage. Since there may be a limit (e.g., imposed by the storage provider) to how much total storage can be used, some data may need to be removed to make room for additional data. A DECADE-compatible client should be able to explicitly remove particular data. This may be implemented using existing protocols. 5.3. Multiple writing REQUIREMENT(S): A DECADE-compatible server MUST NOT allow multiple simultaneous writers for the same object. A DECADE-compatible server SHOULD respond to each of the writers with error condition indicating the attempt of simultaneous writing. RATIONALE: This avoids data corruption in a simple way while remaining efficient. Alternately, the DECADE-compatible server would need to either manage locking, handle write collisions, or merge data, all of which reduce efficiency and increase complexity. EXCEPTION: While a DECADE-compatible server is in the situation that is described in Section 4.1.2.2 or Section 4.1.3.1, it need not generate a response. 5.4. Multiple reading REQUIREMENT(S): A DECADE-compatible server MUST allow for multiple simultaneous readers for an object. RATIONALE: One characteristic of Target Applications is the ability to upload an object to multiple clients. Thus, it is natural for DECADE-compatible server to allow multiple readers to read the content concurrently. 5.5. Reading before completely written REQUIREMENT(S): A DECADE-compatible server MAY allow readers to read from objects before they have been completely written. In case of object writing error, DECADE-compatible server SHOULD be able to respond to the reading DECADE-compatible client with error condition indicating that the object writing is failed. Gu, et al. Expires September 13, 2012 [Page 19] Internet-Draft DECADE Requirements March 2012 RATIONALE: Some Target Applications (in particular, P2P streaming) can be sensitive to latency. A technique to reduce latency is to remove store-and-forward delays for data objects (e.g., make the object available before it is completely written). Appropriate handling for error conditions (e.g., a disappearing writer) needs to be specified. EXCEPTION: While a DECADE-compatible server is in the situation that is described in Section 4.1.2.2 or Section 4.1.3.1, it need not generate a response. 5.6. Writing model REQUIREMENT(S): A DECADE-compatible server MUST provide at least a writing model (while writing an object) that appends data to data already written. RATIONALE: Depending on the object size (e.g., chunk size) used by a Target Application, the application may need to send data to the DECADE-compatible server in multiple packets. To keep implementation simple, the DECADE-compatible server must at least support the ability to write the data sequentially in the order received. Implementations MAY allow application to write data in an object out-of-order (but MUST NOT overwrite ranges of the object that have already been written). 5.7. Storage Status REQUIREMENT(S): A DECADE-compatible server MUST be able to respond resource usage and resource quotas. A minimum set of storage status supported by DECADE-compatible server MUST include resource usage resulting from the client's own usage (including list of written data objects) and usage by other clients that have been authorized to read/write objects on that client's storage. A DECADE-compatible server MUST be able to authenticate the request. RATIONALE: The resources used by a client are not necessarily directly-attached (e.g., disk, network interface, etc). Thus, the client cannot locally determine how such resources are being used. Before storing and retrieving data, a client should be able to determine which data is available (e.g., after an application restart). Gu, et al. Expires September 13, 2012 [Page 20] Internet-Draft DECADE Requirements March 2012 6. Discovery Requirements 6.1. Requirements 6.1.1. Support for Clients Behind NATs and Firewalls REQUIREMENT(S): The mechanism for discovering a DECADE-compatible server MUST be operable by DECADE-compatible clients operating behind NATs and Firewalls. RATIONALE: NATs and Firewalls are prevalent in network deployments, and it is common for Target Applications that include a DECADE- compatible client to be deployed behind these devices. 6.1.2. Prefer Existing Protocols REQUIREMENT(S): The mechanism for discovering a DECADE-compatible server SHOULD leverage existing mechanisms and protocols wherever possible. No new discovery mechanism will be defined unless there is enough evidence that no existing mechanism can work. RATIONALE: Existing protocols such as DNS and DHCP are widespread. Using existing protocols, or combinations of the protocols that have been specified in other contexts, is strictly preferred over developing a new discovery protocol. 7. Security Considerations The security model is an important component of a DECADE-compatible system. It is crucial for users to be able to manage and limit distribution of content to only authorized parties, and the mechanism needs to work on the general Internet which spans multiple administrative and security domains. Previous sections have enumerated detailed requirements, but this section discusses the overall approach and other considerations that do not merit requirements. 7.1. Authentication and Authorization A DECADE-compatible server must authenticate any DECADE-compatible client that attempts to access the in-network storage. DECADE- compatible server is not involved in the authorization between DECADE clients and remote clients, or the authorization between DECADE system user and DECADE service provider. In order to authenticate an accessing DECADE client, a DECADE-compatible server may need to accept the authentication and authorization referral by another DECADE-compatible client. Gu, et al. Expires September 13, 2012 [Page 21] Internet-Draft DECADE Requirements March 2012 7.2. Encrypted Data DECADE-compatible Servers provide the ability to write raw data objects (subject to any policies instituted by the owner/ administrator of the service provider). Thus, DECADE-compatible clients may opt to encrypt data before it is transported to the server. However, DECADE-compatible protocol(s) do not provide encryption of data objects other than that provided by Section 4.1.2.1. 7.3. Protection against Gaming The particular resource control policy communicated by DECADE- compatible protocol(s) and enforced on DECADE-compatible server may be open to certain gaming by clients. For example by specifying many small chunks to increase total throughput or inciting overload conditions are techniques that may be used by a client. 8. IANA Considerations There are no IANA considerations with this document. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [I-D.ietf-decade-problem-statement] Song, H., Zong, N., Yang, Y., and R. Alimi, "DECoupled Application Data Enroute (DECADE) Problem Statement", draft-ietf-decade-problem-statement-03 (work in progress), March 2011. 9.2. Informative References [I-D.ietf-decade-arch] Alimi, R., Yang, Y., Rahman, A., Kutscher, D., and H. Liu, "DECADE Architecture", draft-ietf-decade-arch-02 (work in progress), July 2011. [LLSB08] Levin, D., LaCurts, K., Spring, N., and B. Bhattacharjee, "BitTorrent is an Auction: Analyzing and Improving BitTorrent's Incentives", SIGCOMM 2008, August 2008. Gu, et al. Expires September 13, 2012 [Page 22] Internet-Draft DECADE Requirements March 2012 [PPLive] "PPLive", . Appendix A. Acknowledgments We would also like to thank Haibin Song for substantial contributions to earlier versions of this document. We would also like to thank Reinaldo Penno, Alexey Melnikov, Rich Woundy, Ning Zong, Roni Even, David McDysan, Borje Ohlman, Dirk Kutscher, Akbar Rahman, Xiao Zhu, Yunfei Zhang, and Jin Peng for contributions and general feedback. Authors' Addresses Yingjie Gu Huawei No. 101 Software Avenue Nanjing, Jiangsu Province 210012 P.R.China Phone: +86-25-56624760 Email: guyingjie@huawei.com David A. Bryan Polycom, Inc. Email: dbryan@ethernot.org Yang Richard Yang Yale University Email: yry@cs.yale.edu Richard Alimi Google Email: ralimi@google.com Gu, et al. Expires September 13, 2012 [Page 23]