draft-ietf-decade-reqs-02.txt   draft-ietf-decade-reqs-03.txt 
DECADE Y. Gu DECADE Y. Gu
Internet-Draft Huawei Internet-Draft Huawei
Intended status: Informational D. Bryan Intended status: Informational D. Bryan
Expires: November 18, 2011 Cogent Force, LLC / Huawei Expires: January 12, 2012 Polycom, Inc.
Y. Yang Y. Yang
Yale University Yale University
R. Alimi R. Alimi
Google Google
May 17, 2011 July 11, 2011
DECADE Requirements DECADE Requirements
draft-ietf-decade-reqs-02 draft-ietf-decade-reqs-03
Abstract Abstract
The target of DECoupled Application Data Enroute (DECADE) is to The target of DECoupled Application Data Enroute (DECADE) is to
provide an open and standard in-network storage system for provide an open and standard in-network storage system for
applications, primarily P2P applications, to store, retrieve and applications, primarily P2P (peer-to-peer) applications, to store,
manage their data. This draft enumerates and explains requirements, retrieve and manage their data. This draft enumerates and explains
not only for store and retrieve, but also for data management, access requirements, not only for store and retrieve, but also for data
control and resource control, that should be considered during the management, access control and resource control, that should be
design and implementation of a DECADE system. These are requirements considered during the design and implementation of a DECADE system.
on the entire system; some of the requirements may eventually be These are requirements on the entire system; some of the requirements
implemented by an existing protocol with/without some extensions may eventually be implemented by an existing protocol with/without
(e.g., the data transport level). A user of DECADE as a complete some extensions (e.g., a protocol used to read and write data from
architecture would be guaranteed complete functionality. the storage system). A user of DECADE as a complete architecture
would be guaranteed complete functionality.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
skipping to change at page 2, line 4 skipping to change at page 2, line 5
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 18, 2011. This Internet-Draft will expire on January 12, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 11 skipping to change at page 3, line 11
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology and Concepts . . . . . . . . . . . . . . . . . . . 5 2. Terminology and Concepts . . . . . . . . . . . . . . . . . . . 5
3. Requirements Structure . . . . . . . . . . . . . . . . . . . . 6 3. Requirements Structure . . . . . . . . . . . . . . . . . . . . 6
4. Protocol Requirements . . . . . . . . . . . . . . . . . . . . 7 4. Protocol Requirements . . . . . . . . . . . . . . . . . . . . 7
4.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Overall Protocol Requirements . . . . . . . . . . . . . . 7
4.1.1. Overall Protocol Requirements . . . . . . . . . . . . 7 4.1.1. Metadata and Cross-platform Access . . . . . . . . . . 7
4.1.1.1. Cross-platform Access . . . . . . . . . . . . . . 7 4.1.2. Connectivity Concerns . . . . . . . . . . . . . . . . 7
4.1.1.2. Connectivity Concerns . . . . . . . . . . . . . . 7 4.1.2.1. NATs and Firewalls . . . . . . . . . . . . . . . . 7
4.1.1.2.1. NATs and Firewalls . . . . . . . . . . . . . . 7 4.1.2.2. Connections to Clients . . . . . . . . . . . . . . 8
4.1.1.2.2. Connections to Clients . . . . . . . . . . . . 7 4.1.3. Security . . . . . . . . . . . . . . . . . . . . . . . 8
4.1.1.3. Security . . . . . . . . . . . . . . . . . . . . . 8 4.1.3.1. Secure Transport . . . . . . . . . . . . . . . . . 8
4.1.1.3.1. Secure Transport . . . . . . . . . . . . . . . 8 4.1.4. Error and Failure Conditions . . . . . . . . . . . . . 8
4.1.1.3.2. Connections to Clients . . . . . . . . . . . . 8 4.1.4.1. Overload Condition . . . . . . . . . . . . . . . . 8
4.1.1.4. Error and Failure Conditions . . . . . . . . . . . 8 4.1.4.2. Insufficient Resources . . . . . . . . . . . . . . 8
4.1.1.4.1. Overload Condition . . . . . . . . . . . . . . 8 4.1.4.3. Unavailable and Deleted Data . . . . . . . . . . . 9
4.1.1.4.2. Insufficient Resources . . . . . . . . . . . . 8 4.1.4.4. Redirection . . . . . . . . . . . . . . . . . . . 9
4.1.1.4.3. Unavailable and Deleted Data . . . . . . . . . 9 4.2. Transfer and Latency Requirements . . . . . . . . . . . . 9
4.1.1.4.4. Redirection . . . . . . . . . . . . . . . . . 9 4.2.1. Low-Latency Access . . . . . . . . . . . . . . . . . . 9
4.1.2. Transfer and Latency Requirements . . . . . . . . . . 9 4.2.2. Data Object Size . . . . . . . . . . . . . . . . . . . 10
4.1.2.1. Low-Latency Access . . . . . . . . . . . . . . . . 9 4.2.3. Communication among DECADE Servers . . . . . . . . . . 10
4.1.2.2. Indirect Transfer . . . . . . . . . . . . . . . . 10 4.3. Data Access Requirements . . . . . . . . . . . . . . . . . 11
4.1.2.3. Data Object Size . . . . . . . . . . . . . . . . . 10 4.3.1. Reading/Writing Own Storage . . . . . . . . . . . . . 11
4.1.2.4. Communication among In-network Storage Elements . 10 4.3.2. Access by Other Users . . . . . . . . . . . . . . . . 11
4.1.3. Data Access Requirements . . . . . . . . . . . . . . . 11 4.3.3. Negotiable Data Transport Protocol . . . . . . . . . . 11
4.1.3.1. Reading/Writing Own Storage . . . . . . . . . . . 11 4.3.4. Separation of Data and Control Policies . . . . . . . 12
4.1.3.2. Access by Other Users . . . . . . . . . . . . . . 11 4.4. Data Management Requirements . . . . . . . . . . . . . . . 12
4.1.3.3. Negotiable Data Protocol . . . . . . . . . . . . . 11 4.4.1. Agnostic of reliability . . . . . . . . . . . . . . . 12
4.1.3.4. Separation of Data Operations from Application 4.4.2. Time-to-live for Written Data Objects . . . . . . . . 12
Control . . . . . . . . . . . . . . . . . . . . . 12 4.4.3. Offline Usage . . . . . . . . . . . . . . . . . . . . 13
4.1.4. Data Management Requirements . . . . . . . . . . . . . 12 4.5. Data Naming Requirements . . . . . . . . . . . . . . . . . 13
4.1.4.1. Agnostic of reliability . . . . . . . . . . . . . 12 4.5.1. Unique Names . . . . . . . . . . . . . . . . . . . . . 13
4.1.4.2. Time-to-live for Stored Data . . . . . . . . . . . 13 4.6. Resource Control . . . . . . . . . . . . . . . . . . . . . 13
4.1.4.3. Offline Usage . . . . . . . . . . . . . . . . . . 13 4.6.1. Multiple Applications . . . . . . . . . . . . . . . . 13
4.1.5. Data Naming Requirements . . . . . . . . . . . . . . . 13 4.6.2. Per-Remote-Client, Per-Data Control . . . . . . . . . 14
4.1.5.1. Unique Names . . . . . . . . . . . . . . . . . . . 13 4.6.3. Server Involvement . . . . . . . . . . . . . . . . . . 14
4.1.6. Resource Control . . . . . . . . . . . . . . . . . . . 14 4.7. Authorization . . . . . . . . . . . . . . . . . . . . . . 15
4.1.6.1. Multiple Applications . . . . . . . . . . . . . . 14 4.7.1. Per-Remote-Client, Per-Data Read Access . . . . . . . 15
4.1.6.2. Per-Remote-Client, Per-Data Control . . . . . . . 14 4.7.2. Per-User Write Access . . . . . . . . . . . . . . . . 15
4.1.6.3. Server Involvement . . . . . . . . . . . . . . . . 15 4.7.3. Default Access Permissions . . . . . . . . . . . . . . 15
4.1.7. Authorization . . . . . . . . . . . . . . . . . . . . 15 4.7.4. Authorization Checks . . . . . . . . . . . . . . . . . 15
4.1.7.1. Per-Remote-Client, Per-Data Read Access . . . . . 15 4.7.5. Cryptographic Credentials . . . . . . . . . . . . . . 16
4.1.7.2. Per-User Write Access . . . . . . . . . . . . . . 15 4.7.6. Server Involvement . . . . . . . . . . . . . . . . . . 16
4.1.7.3. Authorization Checks . . . . . . . . . . . . . . . 16 4.7.7. Protocol Reuse . . . . . . . . . . . . . . . . . . . . 16
4.1.7.4. Credentials Not IP-Based . . . . . . . . . . . . . 16 5. Storage Requirements . . . . . . . . . . . . . . . . . . . . . 16
4.1.7.5. Server Involvement . . . . . . . . . . . . . . . . 16 5.1. Immutable Data . . . . . . . . . . . . . . . . . . . . . . 16
5. Discovery Requirements . . . . . . . . . . . . . . . . . . . . 16 5.2. Explicit Deletion of Data . . . . . . . . . . . . . . . . 17
5.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 16 5.3. Multiple writing . . . . . . . . . . . . . . . . . . . . . 17
5.1.1. Locating DECADE Servers . . . . . . . . . . . . . . . 17 5.4. Multiple reading . . . . . . . . . . . . . . . . . . . . . 17
5.1.2. Support for Clients Behind NATs and Firewalls . . . . 17 5.5. Reading before completely written . . . . . . . . . . . . 18
5.1.3. Prefer Existing Protocols . . . . . . . . . . . . . . 17 5.6. Hints concerning usage of written data . . . . . . . . . . 18
6. Storage Requirements . . . . . . . . . . . . . . . . . . . . . 17 5.7. Writing model . . . . . . . . . . . . . . . . . . . . . . 18
6.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 17 5.8. Storage Status . . . . . . . . . . . . . . . . . . . . . . 18
6.1.1. Explicit Deletion of Stored Data . . . . . . . . . . . 17 6. Discovery Requirements . . . . . . . . . . . . . . . . . . . . 19
6.1.2. Multiple writing . . . . . . . . . . . . . . . . . . . 18 6.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 19
6.1.3. Multiple reading . . . . . . . . . . . . . . . . . . . 18 6.1.1. Locating DECADE Servers . . . . . . . . . . . . . . . 19
6.1.4. Reading before completely written . . . . . . . . . . 18 6.1.2. Support for Clients Behind NATs and Firewalls . . . . 19
6.1.5. Hints concerning usage stored data . . . . . . . . . . 18 6.1.3. Prefer Existing Protocols . . . . . . . . . . . . . . 20
6.1.6. Writing model . . . . . . . . . . . . . . . . . . . . 19 7. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.1.7. Storage Status . . . . . . . . . . . . . . . . . . . . 19 7.1. Non-IAP Internal Protocols . . . . . . . . . . . . . . . . 20
6.2. Non-Requirements . . . . . . . . . . . . . . . . . . . . . 19 7.2. Fairness . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.2.1. No ability to update . . . . . . . . . . . . . . . . . 20 7.3. Removal of Duplicate Data Objects . . . . . . . . . . . . 20
7. Implementation Considerations . . . . . . . . . . . . . . . . 20 7.4. Gaming of the Resource Control Mechanism . . . . . . . . . 21
7.1. Resource Scheduling . . . . . . . . . . . . . . . . . . . 20 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21
7.2. Removal of Duplicate Records . . . . . . . . . . . . . . . 20 8.1. Authentication and Authorization . . . . . . . . . . . . . 21
8. Discussion and Open Issues . . . . . . . . . . . . . . . . . . 21 8.2. Encrypted Data . . . . . . . . . . . . . . . . . . . . . . 21
8.1. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 21 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
8.2. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 21 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 10.1. Normative References . . . . . . . . . . . . . . . . . . . 22
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 10.2. Informative References . . . . . . . . . . . . . . . . . . 22
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
11.1. Normative References . . . . . . . . . . . . . . . . . . . 22
11.2. Informative References . . . . . . . . . . . . . . . . . . 22
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 22 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
The object of DECoupled Application Data Enroute (DECADE) is to The object of DECoupled Application Data Enroute (DECADE) is to
provide an open and standard in-network storage system for provide an open and standard in-network storage system for content
applications, primarily applications that could be implemented using distribution applications, where data is typically broken in to one
a content distribution paradigm, where data is broken in to one or or more chunks and then distributed. This may already include many
more chunks and then distributed. This may already include many types of applications including P2P applications, IPTV (Internet
types of applications including P2P applications, IPTV, and VoD. Protocol Television), and VoD (Video on Demand). (For a precise
Instead of always transferring data directly from a source/owner definition of the applications targeted in DECADE, see the definition
client to a requesting client, the source/owner client can store and for Target Application in Section 2.) Instead of always transferring
manage its content on its in-network storage. The requesting client data directly from a source/owner client to a requesting client, the
can get the address of the in-network storage pertaining to the source/owner client can write to and manage its content on its in-
source/owner client and retrieve data from the storage. 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 This draft enumerates and explains the rationale behind SPECIFIC
requirements on the protocol design and on any data store requirements on the protocol design and on any data store
implementation that may be used to implement DECADE servers that implementation that may be used to implement DECADE servers that
should be considered during the design and implementation of a DECADE should be considered during the design and implementation of a DECADE
system. As such, it DOES NOT include general guiding principals. system. As such, it DOES NOT include general guiding principles.
General design considerations, explanation of the problem being General design considerations, explanation of the problem being
addressed, and enumeration of the types of applications to which addressed, and enumeration of the types of applications to which
DECADE may be suited is not considered in this document. For general DECADE may be suited is not considered in this document. For general
information, please see the problem statement information, please see the problem statement
[I-D.ietf-decade-problem-statement] and architecture drafts. [I-D.ietf-decade-problem-statement] and architecture drafts.
This document enumerates the requirements to enable target This document enumerates the requirements to enable target
applications to utilize in-network storage. In this context, using applications to utilize in-network storage. In this context, using
storage resources includes not only basic capabilities such as storage resources includes not only basic capabilities such as
storing and retrieving data, and managing data, but also (1) writing, reading, and managing data, but also controlling access for
controlling access for particular remote clients with which it is particular remote clients with which it is sharing data.
sharing data and (2) controlling the resources used by remote clients Additionally, we also consider controlling the resources used by
when they access data. remote clients when they access data as an integral part of utilizing
the network storage.
2. Terminology and Concepts 2. Terminology and Concepts
This document uses terms defined in This document uses terms defined in
[I-D.ietf-decade-problem-statement]. In particular, IAP refers to [I-D.ietf-decade-problem-statement]. In particular, IAP refers to
the In-network storage Access Protocol, which is the protocol used to the In-network storage Access Protocol, which is the protocol used to
communicate between a DECADE client and DECADE server (in-network communicate between a DECADE client and DECADE server (in-network
storage) for access control and resource control. storage) for access control and resource control.
This document also defines additional terminology: This document also defines additional terminology:
Target Application: An application (typically installed at end-hosts) Target Application: An application (typically installed at end-hosts)
with the ability to explicitly control usage of network and/or with the ability to explicitly control usage of network and/or
storage resources to deliver contents to a large number of users. storage resources to deliver content to a large number of users.
This includes scenarios where multiple applications or entities This includes scenarios where multiple applications or entities
cooperate, such as with P2P/CDN hybrid architectures. Such cooperate, such as with P2P (peer-to-peer) / CDN (Content
applications distribute large contents (e.g., a large file, or video Distribution Network) hybrid architectures. Such applications
stream) by dividing the contents into smaller blocks for more distribute large amounts of content (e.g., a large file, or video
flexible distribution (e.g., multipath). The distributed content is stream) by dividing the content into smaller blocks for more flexible
typically immutable (though it may be deleted). We use the term distribution (e.g., over multiple application-level paths). The
Target Application to refer to the type of applications that are distributed content is typically immutable (though it may be
explicitly (but not exclusively) supported by DECADE. deleted). We use the term Target Application to refer to the type of
applications that are explicitly (but not exclusively) supported by
DECADE.
3. Requirements Structure 3. Requirements Structure
The DECADE protocol is intended to sit between Target Applications The DECADE protocol is intended to sit between Target Applications
and a back-end storage system. In the development of DECADE, it must and a back-end storage system. DECADE does not intend to develop yet
be made clear that the intention is to NOT develop yet another another storage system, but rather to create a protocol that enables
storage system, but rather to create a protocol that enables Target Target Applications to make use of storage within the network,
Applications to make use of storage within the network, leaving leaving specific storage system considerations to the implementation
specific storage system considerations to the implementation of the of the DECADE servers as much as possible. For this reason, we have
DECADE servers as much as possible. For this reason, we have divided divided the requirements into two primary categories:
the requirements into two categories:
o Protocol Requirements: Protocol requirements for Target o Protocol Requirements: Protocol requirements for Target
Applications to make use of in-network storage within their own Applications to make use of in-network storage within their own
data dissemination schemes. Development of these requirements is data dissemination schemes. Development of these requirements is
guided by a study of data access, search and management guided by a study of data access, search and management
capabilities used by Target Applications. These requirements may capabilities used by Target Applications. These requirements may
be met by a new protocol to be defined within the DECADE Working be met by a new protocol to be defined within the DECADE Working
Group. Group.
o Storage Requirements: Functional requirements necessary for the o Storage Requirements: Functional requirements necessary for the
back-end storage system employed by the DECADE server. back-end storage system employed by the DECADE server.
Development of these requirements is guided by a study of the data Development of these requirements is guided by a study of the data
access patterns used by Target Applications. These requirements access patterns used by Target Applications. These requirements
should be met by the underling data transport used by DECADE. should be met by the underlying data transport used by DECADE. In
this document, we use "data transport" to refer to a protocol used
to read and write data from DECADE in-network storage.
Note that a third category also enumerates requirements on the
protocol used to discovery DECADE Servers.
It should also be made clear that the approach is to make DECADE a It should also be made clear that the approach is to make DECADE a
simple protocol, while still enabling its usage within many Target simple protocol, while still enabling its usage within many Target
Applications. For this reason, and to further reinforce the Applications. For this reason, and to further reinforce the
distinction between DECADE and a storage system, in some cases we distinction between DECADE and a storage system, in some cases we
also highlight the non-requirements of the protocol. These non- also highlight the non-requirements of the protocol. These non-
requirements are intended to capture behaviors that will NOT be requirements are intended to capture behaviors that will NOT be
assumed to be needed by DECADE's Target Applications and hence not assumed to be needed by DECADE's Target Applications and hence not
present in the DECADE protocol. present in the DECADE protocol.
Finally, some implementation considerations are provided, which while Finally, some implementation considerations are provided, which while
strictly are not requirements, are intended to provide guidance and not strictly requirements, are intended to provide guidance and
highlight potential points of concern that need to be considered by highlight potential points that need to be considered by the protocol
the protocol developers, and later by implementors. developers, and later by implementors.
4. Protocol Requirements 4. Protocol Requirements
4.1. Requirements This section details the requirements of the DECADE IAP.
4.1.1. Overall Protocol Requirements 4.1. Overall Protocol Requirements
4.1.1.1. Cross-platform Access 4.1.1. Metadata and Cross-platform Access
REQUIREMENT(S): If DECADE supports the ability to store metadata REQUIREMENT(S): If DECADE supports the ability to associate metadata
associated with data objects, the DECADE protocol(s) MUST with data objects, the DECADE protocol(s) MUST transmit any
transmit any metadata using an operating system-independent and metadata using an operating system-independent and architecture-
architecture-independent format. independent standard format.
RATIONALE: If DECADE supports the possibility for storing metadata RATIONALE: If DECADE supports storing metadata (e.g., a description,
(e.g., a description, uploaded date, object size, or access uploaded date, object size), a possible use for the metadata is
control list), a possible use for the metadata is to help a to help a DECADE client locate a desired data object. Data
DECADE client locate a desired data object. Data objects may be objects may be written by DECADE clients running on various
stored by DECADE clients running on various platforms. To enable platforms. To enable metadata to be readable regardless of its
metadata to be readable regardless of its source it must be source it must be transmitted to and from the DECADE server in a
transmitted to and from the DECADE server in a standard format. standard format.
4.1.1.2. Connectivity Concerns 4.1.2. Connectivity Concerns
4.1.1.2.1. NATs and Firewalls 4.1.2.1. NATs and Firewalls
REQUIREMENT(S): DECADE SHOULD be usable across firewalls and NATs REQUIREMENT(S): DECADE SHOULD be usable across firewalls and NAT
without requiring additional network support (e.g., Application- (Network Address Translation) devices without requiring
level Gateways). additional network support (e.g., Application-level Gateways).
RATIONALE: Firewalls and NATs are widely used in the Internet today, RATIONALE: Firewalls and NATs are widely used in the Internet today,
both in ISP networks and within households. Deployment of DECADE both in ISP (Internet Service Provider) and Enterprise networks
must not require modifications to such devices (beyond, perhaps, and by consumers. Deployment of DECADE must not require
reconfiguration). Note that this requirement applies to both any modifications to such devices (beyond, perhaps, reconfiguration).
new protocol developed by the DECADE Working Group and any data Note that this requirement applies to both any new protocol
transport used with DECADE. developed by the DECADE Working Group and any data transport used
with DECADE.
4.1.1.2.2. Connections to Clients 4.1.2.2. Connections to Clients
REQUIREMENT(S): DECADE SHOULD require that network connections be REQUIREMENT(S): DECADE SHOULD require that network connections be
made from DECADE clients to DECADE servers (i.e., not to the made from DECADE clients to DECADE servers (i.e., not from the
DECADE client). server to the DECADE client).
RATIONALE: Many household networks and operating systems have RATIONALE: Many household networks and operating systems have
firewalls and NATs configured by default. To ease deployment by firewalls and NATs configured by default to block incoming
avoiding configuration changes and help mitigate security risks, connections. To ease deployment by avoiding configuration
DECADE should not require clients to listen for any incoming changes and help mitigate security risks, DECADE should not
network connections (beyond what is required by any other require clients to listen for any incoming network connections
already-deployed application). (beyond what is required by any other already-deployed
application).
4.1.1.3. Security 4.1.3. Security
4.1.1.3.1. Secure Transport 4.1.3.1. Secure Transport
REQUIREMENT(S): DECADE MUST contain a mode in which all REQUIREMENT(S): DECADE MUST contain a mode in which all
communication between a DECADE client and server is over a secure communication between a DECADE client and server is over a secure
transport that provides confidentiality, integrity, and transport that provides confidentiality, integrity, and
authentication. authentication.
RATIONALE: Target Applications may wish to store sensitive data. To RATIONALE: Target Applications may wish to write sensitive data. To
satisfy this use case, DECADE must provide a mode in which all satisfy this use case, DECADE must provide a mode in which all
communication between a DECADE client and server occurs over a communication between a DECADE client and server occurs over a
secure transport protocol (e.g., SSL/TLS). secure transport protocol (e.g., SSL/TLS).
4.1.1.3.2. Connections to Clients 4.1.4. Error and Failure Conditions
REQUIREMENT(S): DECADE SHOULD require that network connections be
made from DECADE clients to DECADE servers (i.e., not to the
DECADE client).
RATIONALE: Many household networks and operating systems have
firewalls and NATs configured by default. To ease deployment by
avoiding configuration changes and help mitigate security risks,
DECADE should not require clients to listen for any incoming
network connections (beyond what is required by any other
already-deployed application).
4.1.1.4. Error and Failure Conditions
4.1.1.4.1. Overload Condition 4.1.4.1. Overload Condition
REQUIREMENT(S): In-network storage, which is operating close to its REQUIREMENT(S): In-network storage, which is operating close to its
capacity limit (e.g., too busy servicing other requests), MUST be capacity limit (e.g., too busy servicing other requests), MUST be
able to reject requests and not be required to generate responses able to reject requests and not be required to generate responses
to additional requests. to additional requests.
RATIONALE: When in-network storage is operating at a limit where it RATIONALE: Forcing the in-network storage to respond to requests
may not be able to process additional requests, it should not be when operating close to its capacity can impair its ability to
required to generate responses to such additional requests. service existing requests, and thus is permitted to avoid
Forcing the in-network storage to do so can impair its ability to generating responses to additional requests.
service existing requests.
4.1.1.4.2. Insufficient Resources 4.1.4.2. Insufficient Resources
REQUIREMENT(S): DECADE MUST support an error condition indicating to REQUIREMENT(S): DECADE MUST support an error condition indicating to
a DECADE client that resources (e.g., storage space) were not a DECADE client that resources (e.g., storage space) were not
available to service a request (e.g., storage quota exceeded when available to service a request (e.g., storage quota exceeded when
attempting to store data). attempting to write data).
RATIONALE: The currently-used resource levels within the in-network RATIONALE: The currently-used resource levels within the in-network
storage are not locally-discoverable, since the resources (disk, storage are not locally-discoverable, since the resources (disk,
network interfaces, etc) are not directly attached. In order to network interfaces, etc) are not directly attached. In order to
allocate resources appropriately amongst remote clients, a client allocate resources appropriately amongst remote clients, a client
must be able to determine when resource limits have been reached. must be able to determine when resource limits have been reached.
The client can then respond by explicitly freeing necessary The client can then respond by explicitly freeing necessary
resources or waiting for such resources to be freed. resources or waiting for such resources to be freed.
4.1.1.4.3. Unavailable and Deleted Data 4.1.4.3. Unavailable and Deleted Data
REQUIREMENT(S): DECADE MUST support error conditions indicating that REQUIREMENT(S): DECADE MUST support error conditions indicating that
(1) data was rejected from being stored, (2) deleted, or (3) (1) data was rejected from being written, (2) deleted, or (3)
marked unavailable by a storage provider. marked unavailable by a storage provider.
RATIONALE: Storage providers may require the ability to (1) avoid RATIONALE: Storage providers may require the ability to (1) avoid
storing, (2) delete, or (3) quarantine certain data that has been storing, (2) delete, or (3) quarantine certain data that has been
identified as illegal (or otherwise prohibited). DECADE does not identified as illegal (or otherwise prohibited). DECADE does not
indicate how such data is identified, but applications using indicate how such data is identified, but applications using
DECADE should not break if a storage provider is obligated to DECADE should not break if a storage provider is obligated to
enforce such policies. Appropriate error conditions should be enforce such policies. Appropriate error conditions should be
indicated to applications. indicated to applications.
4.1.1.4.4. Redirection 4.1.4.4. Redirection
REQUIREMENT(S): DECADE SHOULD support the ability for a DECADE REQUIREMENT(S): DECADE SHOULD support the ability for a DECADE
server to redirect requests to another DECADE server. This may server to redirect requests to another DECADE server. This may
be in response to either an error or failure condition, or to be in response to either an error or failure condition, or to
support capabilities such as load balancing. support capabilities such as load balancing.
RATIONALE: A DECADE server may opt to redirect requests to another RATIONALE: A DECADE server may opt to redirect requests to another
server to support capabilities such as load balancing, or if the server to support capabilities such as load balancing, or if the
implementation decides that another DECADE server is in a better implementation decides that another DECADE server is in a better
position to handle the request due to either its location in the position to handle the request due to either its location in the
network, server status, or other consideration. network, server status, or other consideration.
4.1.2. Transfer and Latency Requirements 4.2. Transfer and Latency Requirements
4.1.2.1. Low-Latency Access 4.2.1. Low-Latency Access
REQUIREMENT(S): DECADE SHOULD provide "low-latency" access for REQUIREMENT(S): DECADE SHOULD provide "low-latency" access for
application clients. DECADE MUST allow clients to specify at application clients. DECADE MUST allow clients to specify at
least two classes of services for service: lowest possible least two classes of services for service: lowest possible
latency and latency non-critical. latency and latency non-critical.
RATIONALE: Some applications may have requirements on delivery time RATIONALE: Some applications may have requirements on delivery time
(e.g., live streaming [PPLive]). The user experience may be (e.g., live streaming [PPLive]). The user experience may be
unsatisfactory if the use of in-network storage results in lower unsatisfactory if the use of in-network storage results in lower
performance than connecting directly to remote clients over a performance than connecting directly to remote clients over a
low-speed, possibly congested uplink. Additionally, the overhead low-speed, possibly congested uplink. Additionally, the overhead
required for control-plane operations in DECADE must not cause required for control-plane operations in DECADE must not cause
the latency to be higher than for a low-speed, possibly congested the latency to be higher than for a low-speed, possibly congested
uplink. While it is impossible to make a guarantee that a system uplink. While it is impossible to make a guarantee that a system
using in-network storage will always outperform a system that using in-network storage will always outperform a system that
does not for every transfer, the overall performance of the does not for every transfer, the overall performance of the
system should be improved compared with direct connections, even system should be improved compared with direct low-speed uplink
considering control overhead. connections, even considering control overhead.
4.1.2.2. Indirect Transfer
REQUIREMENT(S): DECADE MUST allow a user's in-network storage to
directly fetch from other user's in-network storage.
RATIONALE: As an example, a requesting remote client may get the
address of the storage pertaining to the source/owner client and
then tell its own in-network storage to fetch the content from
the source-owner's in-network storage. This helps to avoid extra
transfers across ISP network links where possible.
4.1.2.3. Data Object Size 4.2.2. Data Object Size
REQUIREMENT(S): DECADE MUST allow for efficient data transfer of REQUIREMENT(S): DECADE MUST allow for efficient data transfer of
small objects (e.g., 16KB) between a DECADE client and in-network small objects (e.g., 16KB) between a DECADE client and in-network
storage with minimal additional latency required by the protocol. storage with minimal additional latency imposed by the protocol.
RATIONALE: Though Target Applications are frequently used to share RATIONALE: Though Target Applications are frequently used to share
large amounts of data (e.g., continuous streams or large files), large amounts of data (e.g., continuous streams or large files),
the data itself is typically subdivided into smaller chunks that the data itself is typically subdivided into smaller chunks that
are transferred between clients. Additionally, the small chunks are transferred between clients. Additionally, the small chunks
may have requirements on delivery time (e.g., in a live-streaming may have requirements on delivery time (e.g., in a live-streaming
application). DECADE must enable data to be efficiently application). DECADE must enable data to be efficiently
transferred amongst clients at this granularity. transferred amongst clients at this granularity.
4.1.2.4. Communication among In-network Storage Elements 4.2.3. Communication among DECADE Servers
REQUIREMENT(S): DECADE SHOULD support the ability for two in-network REQUIREMENT(S): DECADE SHOULD support the ability for two in-network
storage elements in different administrative domains to store storage elements in different administrative domains to write
and/or retrieve data directly between each other. If such a and/or read data directly between each other (if authorized as
capability is supported, this MAY be the same (or a subset or described in Section 4.7). If such a capability is supported,
extension of) as the IAP used by clients to access data. this MAY be the same (or a subset or extension of) as the IAP
used by clients to access data.
RATIONALE: Allowing server-to-server communication can reduce RATIONALE: Allowing server-to-server communication can reduce
latency in some common scenarios. Consider a scenario when a latency in some common scenarios. Consider a scenario when a
DECADE client is downloading data into its own storage from DECADE client is downloading data into its own storage from
another client's in-network storage. One possibility is for the another client's in-network storage. One possibility is for the
client to first download the data itself, and then upload it to client to first download the data itself, and then upload it to
its own storage. However, this causes unnecessary latency and its own storage. However, this causes unnecessary latency and
network traffic. Allowing the data to be downloaded from the network traffic. Allowing the data to be downloaded from the
remote in-network storage into the client's own in-network remote in-network storage into the client's own in-network
storage can alleviate both. storage can alleviate both.
4.1.3. Data Access Requirements 4.3. Data Access Requirements
4.1.3.1. Reading/Writing Own Storage 4.3.1. Reading/Writing Own Storage
REQUIREMENT(S): DECADE MUST support the ability for a DECADE client REQUIREMENT(S): DECADE MUST support the ability for a DECADE client
to read data from and write data to its own in-network storage. to read data from and write data to its own in-network storage.
RATIONALE: Two basic capabilities for any storage system are reading RATIONALE: Two basic capabilities for any storage system are reading
and writing data. A DECADE client can read data from and write and writing data. A DECADE client can read data from and write
data to in-network storage space that it owns. data to in-network storage space that it owns.
4.1.3.2. Access by Other Users 4.3.2. Access by Other Users
REQUIREMENT(S): DECADE MUST support the ability for a user to apply REQUIREMENT(S): DECADE MUST support the ability for a user to apply
access control policies to users other than itself for its access control policies to users other than itself for its
storage. The users with whom access is being shared can be under storage. The users with whom access is being shared can be under
a different administrative domain than the user who owns the in- a different administrative domain than the user who owns the in-
network storage. The authorized users may read from or write to network storage. The authorized users may read from or write to
the user's storage. the user's storage.
RATIONALE: Endpoints in Target Applications may be located across RATIONALE: Endpoints in Target Applications may be located across
multiple ISPs under multiple administrative domains. Thus, to be multiple ISPs under multiple administrative domains. Thus, to be
useful by Target Applications, DECADE allows a user to specify useful by Target Applications, DECADE allows a user to implement
access control policies for users that may or may not be known to access control policies for users that may or may not be known to
the user's storage provider. the user's storage provider.
4.1.3.3. Negotiable Data Protocol 4.3.3. Negotiable Data Transport Protocol
REQUIREMENT(S): DECADE MUST support the ability for a DECADE client REQUIREMENT(S): DECADE MUST support the ability for a DECADE client
to negotiate with its in-network storage about which protocol it to negotiate with its in-network storage about which protocol it
can use to read data from and write data to its In-network can use to read data from and write data to its In-network
storage. DECADE MUST specify at least one mandatory protocol to storage. DECADE MUST specify at least one mandatory protocol to
be supported by implementations; usage of a different protocol be supported by implementations; usage of a different protocol
may be selected via negotiation. may be selected via negotiation.
RATIONALE: Since typical data transport protocols (e.g., NFS and RATIONALE: Since typical data transport protocols (e.g., NFS and
WebDAV) already provide read and write operations for network WebDAV) already provide read and write operations for network
storage, it may not be necessary for DECADE to define such storage, it may not be necessary for DECADE to define such
operations in a new protocol. However, because of the particular operations in a new protocol. However, because of the particular
application requirements and deployment considerations, different application requirements and deployment considerations, different
applications may support different protocols. Thus, a DECADE applications may support different protocols. Thus, a DECADE
client must be able to select an appropriate protocol also client must be able to select an appropriate protocol also
supported by the in-network storage. This requirement also supported by the in-network storage. This requirement also
follows as a result of the requirement of Separation of Control follows as a result of the requirement of Separation of Control
and Data Operations (Section 4.1.3.4). and Data Operations (Section 4.3.4).
4.1.3.4. Separation of Data Operations from Application Control 4.3.4. Separation of Data and Control Policies
REQUIREMENT(S): The DECADE IAP MUST only provide a minimal set of REQUIREMENT(S): The DECADE IAP MUST only provide a minimal set of
core operations to support diverse policies implemented and core operations to support diverse policies implemented and
desired by Target Applications. desired by Target Applications.
RATIONALE: Target Applications support many complex behaviors and RATIONALE: Target Applications support many complex behaviors and
diverse policies to control and distribute data, such as (e.g., diverse policies to control and distribute data, such as (e.g.,
search, index, setting permissions/passing authorization tokens). search, index, setting permissions/passing authorization tokens).
Thus, to support such Target Applications, these behaviors must Thus, to support such Target Applications, these behaviors must
be logically separated from the data transfer operations (e.g., be logically separated from the data transfer operations (e.g.,
retrieve, store). Some minimal overlap (for example obtaining read, write). Some minimal overlap (for example obtaining
credentials needed to encrypt or authorize data transfer using credentials needed to encrypt or authorize data transfer using
control operations) may be required to be directly specified by control operations) may be required to be directly specified by
DECADE. DECADE.
4.1.4. Data Management Requirements 4.4. Data Management Requirements
4.1.4.1. Agnostic of reliability 4.4.1. Agnostic of reliability
REQUIREMENT(S): DECADE SHOULD remain agnostic of reliability/ REQUIREMENT(S): DECADE SHOULD remain agnostic of reliability/
fault-tolerance level offered by storage provider. fault-tolerance level offered by storage provider.
RATIONALE: Providers of a DECADE service may wish to offer varying RATIONALE: Providers of a DECADE service may wish to offer varying
levels of service for different applications/users. However, a levels of service for different applications/users. However, a
single compliant DECADE client should be able to use multiple single compliant DECADE client should be able to use multiple
DECADE services with differing levels of service. DECADE services with differing levels of service.
4.1.4.2. Time-to-live for Stored Data 4.4.2. Time-to-live for Written Data Objects
REQUIREMENT(S): DECADE MUST support the ability for a DECADE client REQUIREMENT(S): DECADE MUST support the ability for a DECADE client
to indicate a time-to-live value (or expiration time) indicating to indicate a time-to-live value (or expiration time) indicating
a length of time until particular data can be deleted by the in- a length of time until particular data can be deleted by the in-
network storage element. network storage element.
RATIONALE: Some data stored by a DECADE client may be usable only RATIONALE: Some data objects written by a DECADE client may be
within a certain window of time, such as in live-streaming P2P usable only within a certain window of time, such as in live-
applications. Providing a time-to-live value for stored data streaming P2P applications. Providing a time-to-live value for
(e.g., at the time it is stored) can reduce management overhead data objects (e.g., at the time they are written) can reduce
by avoiding many 'delete' commands sent to in-network storage. management overhead by avoiding many 'delete' commands sent to
The in-network storage may still keep the data in cache for in-network storage. The in-network storage may still keep the
bandwidth optimization. But this is guided by the privacy policy data in cache for bandwidth optimization. But this is guided by
of the DECADE provider. the privacy policy of the DECADE provider.
4.1.4.3. Offline Usage 4.4.3. Offline Usage
REQUIREMENT(S): DECADE MAY support the ability for a user to provide REQUIREMENT(S): DECADE MAY support the ability for a user to provide
authorized access to its in-network storage even if the user has authorized access to its in-network storage even if the user has
no DECADE applications actively running or connected to the no DECADE applications actively running or connected to the
network. network.
RATIONALE: If an application desires, it can authorize remote RATIONALE: If an application desires, it can authorize remote
clients to access its storage even after the application exits or clients to access its storage even after the application exits or
network connectivity is lost. An example use case is mobile network connectivity is lost. An example use case is mobile
scenarios, where a client can lose and regain network scenarios, where a client can lose and regain network
connectivity very often. connectivity very often.
4.1.5. Data Naming Requirements 4.5. Data Naming Requirements
4.1.5.1. Unique Names 4.5.1. Unique Names
REQUIREMENT(S): DECADE SHOULD use a naming scheme in which the name REQUIREMENT(S): DECADE MUST use a naming scheme with an extremely
of a data object is unique from the names of all other data large namespace and mechanisms that ensure that the name of a
objects with different content. data object is statistically unlikely to be the same as the names
of all other data objects (globally) with different content.
DECADE SHOULD provide a mechanism (minimally rejection) to handle
the improbable case of a collision.
RATIONALE: When storing a data object, a DECADE Client should be RATIONALE: When writing a data object, a DECADE Client should be
able to store it without being concerned over whether an object able to write it without being concerned over whether an object
of the same name already exists, unless the existing object of the same name already exists, unless the existing object
contains the exact same data. Note that it may be reasonable for contains the exact same data. Note that it may be reasonable for
DECADE to satisfy this requirement probabilistically (e.g., using DECADE to satisfy this requirement probabilistically (e.g., using
a hashing mechanism). a hashing mechanism). As a result, it is wise to provide a
collision handling mechanism, even if the probability of
collisions is extremely low.
4.1.6. Resource Control 4.6. Resource Control
4.1.6.1. Multiple Applications 4.6.1. Multiple Applications
REQUIREMENT(S): DECADE SHOULD support the ability for users to REQUIREMENT(S): DECADE SHOULD support the ability for users to
define resource sharing policies for multiple applications define resource sharing policies for multiple applications
(DECADE clients) being run/managed by the user. (DECADE clients) being run/managed by the user.
RATIONALE: A user may own in-network storage and share the in- RATIONALE: A user may own in-network storage and share the in-
network storage resources amongst multiple applications. For network storage resources amongst multiple applications. For
example, the user may run a video-on-demand application and a example, the user may run one or more video-on-demand
live-streaming (or even two different live-streaming application(s) and a live-streaming application(s) which both
applications) application which both make use of the user's in- make use of the user's in-network storage. The applications may
network storage. The applications may be running on different be running on different machines and may not directly
machines and may not directly communicate. Thus, DECADE should communicate. Thus, DECADE should enable the user to determine
enable the user to determine resource sharing policies between resource sharing policies between the applications.
the applications.
One possibility is for a user to indicate the particular resource One possibility is for a user to indicate the particular resource
sharing policies between applications out-of-band (not using a sharing policies between applications out-of-band (not using a
standard protocol), but this requirement may manifest itself in standard protocol), but this requirement may manifest itself in
passing values over IAP to identify individual applications. passing values over IAP to identify individual applications.
Such identifiers can be either user-generated or server-generated Such identifiers can be either user-generated or server-generated
and do not need to be registered by IANA. and do not need to be registered by IANA.
4.1.6.2. Per-Remote-Client, Per-Data Control 4.6.2. Per-Remote-Client, Per-Data Control
REQUIREMENT(S): A DECADE client MUST be able to assign resource REQUIREMENT(S): A DECADE client MUST be able to assign resource
quotas to individual remote clients for reading from and writing 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 particular data to its in-network storage within a particular
range of time. The DECADE server MUST enforce these constraints. range of time. The DECADE server MUST enforce these constraints.
RATIONALE: Target Applications can rely on control of resources on a RATIONALE: Target Applications can rely on control of resources on a
per-remote-client or per-data basis. For example, application per-remote-client or per-data basis. For example, application
policy may indicate that certain remote clients have a higher 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 certain data (e.g., chunks) may be distributed with a higher
priority. As another example, when allowing a remote client to priority. As another example, when allowing a remote client to
write data to a user's in-network storage, the remote client may write data to a user's in-network storage, the remote client may
be restricted to write only a certain amount of data. Since the be restricted to write only a certain amount of data. Since the
client may need to manage multiple clients accessing its data, it client may need to manage multiple clients accessing its data, it
should be able to indicate the time over which the granted should be able to indicate the time over which the granted
resources are usable. For example, an expiration time for the resources are usable. For example, an expiration time for the
access could be indicated to the server after which no resources access could be indicated to the server after which no resources
are granted (e.g., indicate error as access denied). are granted (e.g., indicate error as access denied).
4.1.6.3. Server Involvement 4.6.3. Server Involvement
REQUIREMENT(S): A DECADE client SHOULD be able to indicate to a REQUIREMENT(S): A DECADE client SHOULD be able to indicate to a
DECADE server, without itself contacting the server, resource DECADE server, without itself contacting the server, resource
control policies for remote clients' requests. control policies for remote clients' requests.
RATIONALE: One important consideration for in-network storage RATIONALE: One important consideration for in-network storage
elements is scalability, since a single storage element may be elements is scalability, since a single storage element may be
used to support many users. Many Target Applications use small used to support many users. Many Target Applications use small
chunk sizes and frequent data exchanges. If such an application chunk sizes and frequent data exchanges. If such an application
employed resource control and contacted the in-network storage employed resource control and contacted the in-network storage
element for each data exchange, this could present a scalability element for each data exchange, this could present a scalability
challenge for the server as well as additional latency for challenge for the server as well as additional latency for
clients. clients.
An alternative is to let requesting users obtain signed resource An alternative is to let requesting users obtain signed resource
control policies from the owning user, and then users can then control policies (in the form of a token) from the owning user,
present the policy to the storage directly. This can result in and then users can then present the policy to the storage
reduced messaging handled by the in-network storage. directly. This can result in reduced messaging handled by the
in-network storage.
4.1.7. Authorization 4.7. Authorization
4.1.7.1. Per-Remote-Client, Per-Data Read Access 4.7.1. Per-Remote-Client, Per-Data Read Access
REQUIREMENT(S): A DECADE Client MUST be able to control which REQUIREMENT(S): A DECADE Client MUST be able to control which
individual remote clients are authorized to read particular data individual remote clients are authorized to read particular data
stored on its in-network storage. from its in-network storage.
RATIONALE: A Target Application can control certain application- RATIONALE: A Target Application can control certain application-
level policies by sending particular data (e.g., chunks) to level policies by sending particular data (e.g., chunks) to
certain remote clients. It is important that remote clients not certain remote clients. It is important that remote clients not
be able to circumvent such decisions by arbitrarily reading any be able to circumvent such decisions by arbitrarily reading any
currently-stored data in in-network storage. data in in-network storage.
4.1.7.2. Per-User Write Access 4.7.2. Per-User Write Access
REQUIREMENT(S): A DECADE Client MUST be able to control which REQUIREMENT(S): A DECADE Client MUST be able to control which
individual remote clients are authorized to store data into its individual remote clients are authorized to write data into its
in-network storage. in-network storage.
RATIONALE: The space managed by a user in in-network storage can be 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 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 remote clients to write data directly to a user's in-network
storage. Thus, a DECADE client should be able to grant only storage. Thus, a DECADE client should be able to grant only
certain remote clients this privilege. certain remote clients this privilege.
Note that it is not (currently) a requirement to check that a 4.7.3. Default Access Permissions
remote client stores a particular set of data (e.g., the check
that a remote client writes the expected chunk of a file).
Enforcing this as a requirement would require a client to know
which data is expected (e.g., the full chunk itself or a hash of
the chunk) which may not be available in all applications.
Checking for a particular hash could be considered as a
requirement in the future that could optionally be employed by
applications.
4.1.7.3. Authorization Checks 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 is via token passing, resulting in a system with little
state on the server side.
4.7.4. Authorization Checks
REQUIREMENT(S): In-network storage MUST check the authorization of a REQUIREMENT(S): In-network storage MUST check the authorization of a
client before it executes a supplied request. The in-network client before it executes a supplied request. The in-network
storage MAY use optimizations to avoid such authorization checks storage MAY use optimizations to avoid such authorization checks
as long as the enforced permissions are the the same. as long as the enforced permissions are the same.
RATIONALE: Authorization granted by a DECADE client are meaningless RATIONALE: Authorization granted by a DECADE client are meaningless
unless unauthorized requests are denied access. Thus, the in- unless unauthorized requests are denied access. Thus, the in-
network storage element must verify the authorization of a network storage element must verify the authorization of a
particular request before it is executed. particular request before it is executed.
4.1.7.4. Credentials Not IP-Based 4.7.5. Cryptographic Credentials
REQUIREMENT(S): Access MUST be able to be granted on other REQUIREMENT(S): Access MUST be able to be granted using
credentials than the IP address cryptographic credentials.
RATIONALE: DECADE clients may be operating on hosts without constant RATIONALE: DECADE clients may be operating on hosts without constant
network connectivity or without a permanent attachment address network connectivity or without a permanent attachment address
(e.g., mobile devices). To support access control with such (e.g., mobile devices). To support access control with such
hosts, DECADE servers must support access control policies that hosts, DECADE servers must support access control policies that
use information other than IP addresses. use cryptographic credentials, not simply by tying access to IP
addresses.
4.1.7.5. Server Involvement 4.7.6. Server Involvement
REQUIREMENT(S): A DECADE client SHOULD be able to indicate, without REQUIREMENT(S): A DECADE client SHOULD be able to indicate, without
contacting the server itself, access control policies for remote contacting the server itself, access control policies for remote
clients' requests. clients' requests.
RATIONALE: See discussion in Section 4.1.6.3. RATIONALE: See discussion in Section 4.6.3.
5. Discovery Requirements
5.1. Requirements
5.1.1. Locating DECADE Servers
REQUIREMENT(S): The DECADE Discovery mechanism MUST allow a DECADE
Client to identify one or more DECADE Servers to which it is
authorized to read/write data and to which it may authorize other
DECADE Clients to read/write data, or fail if no such DECADE
Servers are available.
RATIONALE: A basic goal of DECADE is to allow DECADE Clients to
read/write data for access by other DECADE Clients or itself.
Executing the Discovery process should result in a DECADE Client
finding a DECADE Server that it can use for these purposes. It
is possible that no such DECADE Servers are available. Note that
even if a DECADE Client may not successfully locate a DECADE
Server that fits these critieria, it may still read/write data a
DECADE Server if authorized by another DECADE Client.
5.1.2. Support for Clients Behind NATs and Firewalls 4.7.7. Protocol Reuse
REQUIREMENT(S): The Discovery mechanism MUST support DECADE Clients REQUIREMENT(S): If possible, DECADE SHOULD reuse existing protocol
operating behind NATs and Firewalls without requiring additional and mechanisms for Authentication, Access, and Authorization
network support (e.g., Application-level Gateways). (AAA).
RATIONALE: NATs and Firewalls are prevalent in network deployments, RATIONALE: If possible, reusing an existing AAA protocol/mechanism
and it is common for Target Applications wishing to include a will minimize the development required by applications, and will
DECADE Client to be deployed behind these devices. maximize interoperability of the DECADE protocol with existing
infrastructure.
5.1.3. Prefer Existing Protocols 5. Storage Requirements
REQUIREMENT(S): The DECADE Server discovery mechanism SHOULD prefer This section details the requirements of the underlying storage used
to use existing mechanisms and protocols wherever possible. to support the DECADE IAP.
RATIONALE: Existing protocols such as DNS and DHCP are widespread. 5.1. Immutable Data
Using existing protocols, or combinations of the protocols that REQUIREMENT(S): DECADE MUST provide the ability to manage data
have been specified in other contexts, is strictly preferred over objects that are immutable once they are written to storage.
developing a new discovery protocol for DECADE.
6. Storage Requirements RATIONALE: Immutable data objects are an important simplification in
DECADE. Reasonable consistency models for updating existing
objects would significantly complicate implementation (especially
if implementation chooses to replicate data across multiple
servers). If a user needs to update a resource, it can write a
new resource and then distribute the new resource instead of the
old one.
6.1. Requirements 5.2. Explicit Deletion of Data
6.1.1. Explicit Deletion of Stored Data
REQUIREMENT(S): DECADE MUST support the ability for a DECADE client REQUIREMENT(S): DECADE MUST support the ability for a DECADE client
to explicitly delete data from its own in-network storage. to explicitly delete data from its own in-network storage.
DECADE MAY have an overwrite flag indicating that an object with
the same name should be replaced.
RATIONALE: A DECADE client may continually be writing data to its RATIONALE: A DECADE client may continually be writing data to its
in-network storage. Since there may be a limit (e.g., imposed by 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 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 data may need to be removed to make room for additional data. A
DECADE client should be able to explicitly remove particular DECADE client should be able to explicitly remove particular
data. This may be implemented using existing protocols. data. This may be implemented using existing protocols.
6.1.2. Multiple writing 5.3. Multiple writing
REQUIREMENT(S): DECADE MUST NOT allow multiple writers for the same REQUIREMENT(S): DECADE MUST NOT allow multiple simultaneous writers
object. Implementations raise an error to one of the writers. for the same object. Implementations MUST raise an error to one
of the writers.
RATIONALE: This avoids data corruption in a simple way while RATIONALE: This avoids data corruption in a simple way while
remaining efficient. remaining efficient. Alternately, the DECADE server would need
to either manage locking, handle write collisions, or merge data,
all of which reduce efficiency and increase complexity.
6.1.3. Multiple reading 5.4. Multiple reading
REQUIREMENT(S): DECADE MUST allow for multiple readers for an REQUIREMENT(S): DECADE MUST allow for multiple simultaneous readers
object. for an object.
RATIONALE: One characteristic of Target Applications is the ability RATIONALE: One characteristic of Target Applications is the ability
to upload an object to multiple clients. Thus, it is natural for to upload an object to multiple clients. Thus, it is natural for
DECADE to allow multiple readers to read the content DECADE to allow multiple readers to read the content
concurrently. concurrently.
6.1.4. Reading before completely written 5.5. Reading before completely written
REQUIREMENT(S): DECADE MAY allow readers to read from objects before REQUIREMENT(S): DECADE MAY allow readers to read from objects before
they have been completely written. they have been completely written.
RATIONALE: Some Target Applications (in particular, P2P streaming) RATIONALE: Some Target Applications (in particular, P2P streaming)
can be sensitive to latency. A technique to reduce latency is to can be sensitive to latency. A technique to reduce latency is to
remove store-and-forward delays for data objects (e.g., make the remove store-and-forward delays for data objects (e.g., make the
object available before it is completely stored). Appropriate object available before it is completely written). Appropriate
handling for error conditions (e.g., a disappearing writer) needs handling for error conditions (e.g., a disappearing writer) needs
to be specified. to be specified.
6.1.5. Hints concerning usage stored data 5.6. Hints concerning usage of written data
REQUIREMENT(S): DECADE MAY allow writers of new objects to indicate REQUIREMENT(S): DECADE MAY allow writers of new objects to indicate
specific hints concerning how the objects are expected to be used specific hints concerning how the objects are expected to be used
(e.g., access frequency or time to live). (e.g., access frequency or time to live).
RATIONALE: Different Target Applications may have different usage RATIONALE: Different Target Applications may have different usage
patterns for objects stored at in-network storage. For example, patterns for objects written to in-network storage. For example,
a P2P live streaming application may indicate to a DECADE server a P2P live streaming application may indicate to a DECADE server
that the objects are expected to have a shore time-to-live, but that the objects are expected to have a shore time-to-live, but
read frequently. The DECADE server may then opt to store the read frequently. The DECADE server may then opt to persist the
objects in memory instead of in disk. objects in memory instead of in disk.
6.1.6. Writing model 5.7. Writing model
REQUIREMENT(S): DECADE MUST provide at least a writing model (while REQUIREMENT(S): DECADE storage MUST provide at least a writing model
storing an object) that appends data to data already stored. (while writing an object) that appends data to data already
written.
RATIONALE: Depending on the object size (e.g., chunk size) used by a RATIONALE: Depending on the object size (e.g., chunk size) used by a
Target Application, the application may need to send data to the Target Application, the application may need to send data to the
DECADE server in multiple packets. To keep implementation DECADE server in multiple packets. To keep implementation
simple, the DECADE must at least support the ability to write the simple, the DECADE must at least support the ability to write the
data sequentially in the order received. Implementations MAY data sequentially in the order received. Implementations MAY
allow application to write data in an object out-of-order (but allow application to write data in an object out-of-order (but
MUST NOT overwrite ranges of the object that have already been MUST NOT overwrite ranges of the object that have already been
stored). written).
6.1.7. Storage Status 5.8. Storage Status
REQUIREMENT(S): A DECADE client MUST be able to retrieve current REQUIREMENT(S): A DECADE client MUST be able to read current
resource usage (including list of stored data), resource quotas, resource usage (including list of written data objects), resource
and access permissions for its in-network storage. The returned quotas, and access permissions for its in-network storage. The
information MUST include resource usage resulting from the returned information MUST include resource usage resulting from
client's own usage and usage by other clients that have been the client's own usage and usage by other clients that have been
authorized to read/write objects or open connections to that authorized to read/write objects or open connections to that
client's storage. client's storage. DECADE protocol(s) MUST support the ability
for a DECADE client to read aggregated resource usage information
(across all other clients to which it has authorized access), and
MAY support the ability to request this information for each
other authorized client.
RATIONALE: The resources used by a client are not directly-attached RATIONALE: The resources used by a client are not directly-attached
(e.g., disk, network interface, etc). Thus, the client cannot (e.g., disk, network interface, etc). Thus, the client cannot
locally determine how such resources are being used. Before locally determine how such resources are being used. Before
storing and retrieving data, a client should be able to determine storing and retrieving data, a client should be able to determine
which data is available (e.g., after an application restart). which data is available (e.g., after an application restart).
Additionally, a client should be able to determine resource Additionally, a client should be able to determine resource
availability to better allocate them to remote clients. availability to better allocate them to remote clients. Due to
scalability issues, it is not required that DECADE support
returning usage information broken down by each remote client
which has been authorized access, but this feature may be useful
in certain deployment scenarios.
6.2. Non-Requirements 6. Discovery Requirements
6.2.1. No ability to update
REQUIREMENT(S): DECADE SHOULD NOT provide ability to update existing 6.1. Requirements
objects. That is, objects are immutable once they are stored.
RATIONALE: Reasonable consistency models for updating existing 6.1.1. Locating DECADE Servers
objects would significantly complicate implementation (especially
if implementation chooses to replicate data across multiple
servers). If a user needs to update a resource, it can store a
new resource and then distribute the new resource instead of the
old one.
7. Implementation Considerations REQUIREMENT(S): The DECADE Discovery mechanism MUST allow a DECADE
Client to identify one or more DECADE Servers to which it is
authorized to read/write data and to which it may authorize other
DECADE Clients to read/write data, or fail if no such DECADE
Servers are available.
The intent of this section is to collect discussion items and RATIONALE: A basic goal of DECADE is to allow DECADE Clients to
implementation considerations that have been discovered as this read/write data for access by other DECADE Clients or itself.
requirements document has been produced. The content of this section Executing the Discovery process should result in a DECADE Client
will be migrated to an appropriate place as the document and the finding a DECADE Server that it can use for these purposes. It
Working Group progress. is possible that no such DECADE Servers are available. Note that
even if a DECADE Client may not successfully locate a DECADE
Server that fits these criteria, it may still read/write data a
DECADE Server if authorized by another DECADE Client.
7.1. Resource Scheduling 6.1.2. Support for Clients Behind NATs and Firewalls
The particular resource scheduling policy may have important REQUIREMENT(S): The Discovery mechanism MUST support DECADE Clients
ramifications on the performance of applications. This document has operating behind NATs and Firewalls without requiring additional
explicitly mentioned simultaneous support for both low-latency network support (e.g., Application-level Gateways).
applications and latency-tolerant applications.
Denial of Service attacks may be another risk. For example, RATIONALE: NATs and Firewalls are prevalent in network deployments,
rejecting new requests due to overload conditions may introduce the and it is common for Target Applications wishing to include a
ability to perform a denial of service attack depending on a DECADE Client to be deployed behind these devices.
particular DECADE server's scheduling implementation and resource
allocation policies.
7.2. Removal of Duplicate Records 6.1.3. Prefer Existing Protocols
There are actually two possible scenarios here. The first is the REQUIREMENT(S): The DECADE Server discovery mechanism SHOULD prefer
case of removing duplicates within one particular DECADE server (or to use existing mechanisms and protocols wherever possible.
logical server). While not a requirement, as it does not impact the
protocol and is technically not noticeable on message across the
wire, a DECADE server may implement internal mechanisms to monitor
for duplicate records and use internal mechanisms to prevent
duplication of internal storage.
The second scenario is removing duplicates across a distributed set RATIONALE: Existing protocols such as DNS and DHCP are widespread.
of DECADE servers. This is a more difficult problem, and if the Using existing protocols, or combinations of the protocols that
group decides to support this capability, it may require protocol have been specified in other contexts, is strictly preferred over
support. See Section 8.2 for more details. developing a new discovery protocol for DECADE.
8. Discussion and Open Issues 7. Discussion
8.1. Discussion 7.1. Non-IAP Internal Protocols
Sometimes, several logical in-network storages could be deployed on Sometimes, several logical in-network storage systems could be
the same physical network device. In this case, in-network storages deployed on the same physical network device. In this case, in-
on the same physical network device can communicate and transfer data network storages on the same physical network device can communicate
through internal communication messages. However in-network storages and transfer data through internal communication messages. However
deployed on different physical network devices SHOULD communicate in-network storages deployed on different physical network devices
with in-network storage Access Protocol (IAP). SHOULD communicate with in-network storage Access Protocol (IAP).
7.2. Fairness
To provide fairness among users, the in-network storage provider To provide fairness among users, the in-network storage provider
should assign resource (e.g., storage, bandwidth, connections) quota should assign resource (e.g., storage, bandwidth, connections) quota
for users. This can prevent a small number of clients from occupying for users. This can prevent a small number of clients from occupying
large amounts of resources on the in-network storage, while others large amounts of resources on the in-network storage, while others
starve. starve.
8.2. Open Issues 7.3. Removal of Duplicate Data Objects
Gaming of the Resource Control Mechanism: There has been some There are actually two possible scenarios. The first is the case of
discussion of how applications may be able game the scheduling removing duplicates within one particular DECADE server (or logical
system by manipulating the resource control mechanism, for server). While not a requirement, as it does not impact the
example by specifying many small peers to increase total protocol, a DECADE server may implement internal mechanisms to
throughput. This is a serious concern, and we need to identify monitor for duplicate objects and use internal mechanisms to prevent
specific requirements on the protocol (hopefully independent of duplication in internal storage.
particular scheduling/resource control schemes) to help address
this.
Discovery: There needs to be some mechanism for a user to discover The second scenario is removing duplicates across a distributed set
that there is a DECADE service available for their use, and to of DECADE servers. DECADE does not explicitly design for this, but
locate that server. This is particularly important in the case does offer a redirection mechanism (Section 4.1.4.4) that is one
of mobile applications, since the actual servers that are primitive that may be used to support this feature in certain
available at any given time may differ. However, the specifics deployment scenarios.
of what mechanisms (DHCP, HTTP page, etc.) have not been
discussed, or even if the protocol should specify one or leave it
as an implementation detail. This needs to be defined, and
specific requirements formulated if needed.
Removal of Duplicate Records Across Servers: If the group wishes to 7.4. Gaming of the Resource Control Mechanism
allow for automated mechanisms to remove duplicates across a
number of separate servers, some protocol support may need to be
added. In the case of removing duplicates within a single
(logical) DECADE server, this is simply an implementation
concern. See Section 7 for more details.
9. Security Considerations The particular resource control policy communicated by a DECADE
protocol and enforced by the scheduling system of a DECADE
implementation may be open to certain gaming by clients. for example
by specifying many small peers to increase total throughput or
inciting overload conditions at a DECADE server. Identifying and
protecting against all such opportunities for gaming is outside the
scope of this document, but DECADE protocol(s) and implementations
SHOULD be aware that opportunities ti game the system may be
attempted.
Authorization for access to in-network storage is an important part 8. Security Considerations
of the requirements listed in this document. Authorization for
access to storage resources and the data itself is important for
users to be able to manage and limit distribution of content. For
example, a user may only wish to share particular content with
certain peers.
If the authorization technique implemented in DECADE passes any The security model is an important component of DECADE. It is
private information (e.g., user passwords) over the wire, it MUST be crucial for users to be able to manage and limit distribution of
passed in a secure way. 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.
10. IANA Considerations 8.1. Authentication and Authorization
DECADE only uses authentication when allowing a particular client to
access its own storage at a server. DECADE servers themselves do not
authenticate other clients which are reading/writing a client's own
storage. Instead, DECADE relies on clients to authenticate others to
access its storage, and then communicate the result of that
authentication to the DECADE server so that the DECADE server may
implement the necessary authorization checks.
8.2. Encrypted Data
DECADE Servers provide the ability to write raw data objects (subject
to any policies instituted by the owner/administrator if the DECADE
server, which are outside of the scope of this document). Thus,
DECADE clients may opt to encrypt data before it is written to the
DECADE Server. However, DECADE itself does not provide encryption of
data objects other than is provided by Section 4.1.3.1.
9. IANA Considerations
There are no IANA considerations with this document. There are no IANA considerations with this document.
11. References 10. References
11.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
11.2. Informative References 10.2. Informative References
[I-D.ietf-decade-problem-statement] [I-D.ietf-decade-problem-statement]
Yongchao, S., Zong, N., Yang, Y., and R. Alimi, "DECoupled Song, H., Zong, N., Yang, Y., and R. Alimi, "DECoupled
Application Data Enroute (DECADE) Problem Statement", Application Data Enroute (DECADE) Problem Statement",
draft-ietf-decade-problem-statement-00 (work in progress), draft-ietf-decade-problem-statement-03 (work in progress),
August 2010. March 2011.
[LLSB08] Levin, D., LaCurts, K., Spring, N., and B. Bhattacharjee, [LLSB08] Levin, D., LaCurts, K., Spring, N., and B. Bhattacharjee,
"BitTorrent is an Auction: Analyzing and Improving "BitTorrent is an Auction: Analyzing and Improving
BitTorrent's Incentives", SIGCOMM 2008, August 2008. BitTorrent's Incentives", SIGCOMM 2008, August 2008.
[PPLive] "PPLive", <http://www.pplive.com>. [PPLive] "PPLive", <http://www.pplive.com>.
Appendix A. Acknowledgments Appendix A. Acknowledgments
We would also like to thank Haibin Song for substantial contributions We would also like to thank Haibin Song for substantial contributions
to earlier versions of this document. We would also like to thank to earlier versions of this document. We would also like to thank
Reinaldo Penno, Alexey Melnikov, Rich Woundy, Ning Zong, Roni Even, Reinaldo Penno, Alexey Melnikov, Rich Woundy, Ning Zong, Roni Even,
David McDysan, Boerje Ohlman and Dirk Kutscher for contributions David McDysan, Boerje Ohlman, Dirk Kutscher, Akbar Rahman, Xiao Zhu,
(including some text used verbatim) and general feedback. Yunfei Zhang, and Jin Peng for contributions and general feedback.
Authors' Addresses Authors' Addresses
Yingjie Gu Yingjie Gu
Huawei Huawei
No. 101 Software Avenue No. 101 Software Avenue
Nanjing, Jiangsu Province 210012 Nanjing, Jiangsu Province 210012
P.R.China P.R.China
Phone: +86-25-56624760 Phone: +86-25-56624760
Email: guyingjie@huawei.com Email: guyingjie@huawei.com
David A. Bryan David A. Bryan
Cogent Force, LLC / Huawei Polycom, Inc.
Email: dbryan@ethernot.org Email: dbryan@ethernot.org
Yang Richard Yang Yang Richard Yang
Yale University Yale University
Email: yry@cs.yale.edu Email: yry@cs.yale.edu
Richard Alimi Richard Alimi
Google Google
Email: ralimi@google.com Email: ralimi@google.com
 End of changes. 142 change blocks. 
418 lines changed or deleted 416 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/