draft-ietf-decade-reqs-05.txt   draft-ietf-decade-reqs-06.txt 
DECADE Y. Gu DECADE Y. Gu
Internet-Draft Huawei Internet-Draft Huawei
Intended status: Informational D. Bryan Intended status: Informational D. Bryan
Expires: May 3, 2012 Polycom, Inc. Expires: September 13, 2012 Polycom, Inc.
Y. Yang Y. Yang
Yale University Yale University
R. Alimi R. Alimi
Google Google
October 31, 2011 March 12, 2012
DECADE Requirements DECADE Requirements
draft-ietf-decade-reqs-05 draft-ietf-decade-reqs-06
Abstract Abstract
The target of DECoupled Application Data Enroute (DECADE) is to The target of the DECoupled Application Data Enroute (DECADE) system
provide an open and standard in-network storage system for is to provide an open and standard in-network storage system for
applications, primarily P2P (peer-to-peer) applications, to store, applications, primarily P2P (peer-to-peer) applications, to store,
retrieve and manage their data. This draft enumerates and explains retrieve and manage their data. This draft enumerates and explains
requirements, not only for storage and retrieval, but also for data requirements, not only for storage and retrieval, but also for data
management, access control and resource control, that should be management, access control and resource control, that should be
considered during the design and implementation of a DECADE system. considered during the design and implementation of a DECADE-
These are requirements on the entire system; some of the requirements compatible system. These are requirements on the entire system; some
may eventually be implemented by an existing protocol with/without of the requirements may eventually be implemented by an existing
some extensions (e.g., a protocol used to read and write data from protocol with/without some extensions (e.g., a protocol used to read
the storage system). The requirements in this document are intended and write data from the storage system). The requirements in this
to ensure that the DECADE architecture includes all of the desired document are intended to ensure that a DECADE-compatible system
functionality for intended applications. architecture includes all of the desired functionality for intended
applications.
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 in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at http://datatracker.ietf.org/drafts/current/.
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 This Internet-Draft will expire on September 13, 2012.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 3, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
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 Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology and Concepts . . . . . . . . . . . . . . . . . . . 6 2. Terminology and Concepts . . . . . . . . . . . . . . . . . . . 6
3. Requirements Structure . . . . . . . . . . . . . . . . . . . . 6 3. Requirements Structure . . . . . . . . . . . . . . . . . . . . 7
4. Protocol Requirements . . . . . . . . . . . . . . . . . . . . 7 4. Protocol Requirements . . . . . . . . . . . . . . . . . . . . 7
4.1. Overall Protocol Requirements . . . . . . . . . . . . . . 7 4.1. Overall Protocol Requirements . . . . . . . . . . . . . . 7
4.1.1. Connectivity Concerns . . . . . . . . . . . . . . . . 7 4.1.1. Connectivity Concerns . . . . . . . . . . . . . . . . 7
4.1.1.1. NATs and Firewalls . . . . . . . . . . . . . . . . 7 4.1.1.1. NATs and Firewalls . . . . . . . . . . . . . . . . 8
4.1.1.2. Connections to Clients . . . . . . . . . . . . . . 7 4.1.1.2. Connections to Clients . . . . . . . . . . . . . . 8
4.1.2. Security . . . . . . . . . . . . . . . . . . . . . . . 8 4.1.2. Security . . . . . . . . . . . . . . . . . . . . . . . 8
4.1.2.1. Secure Transport . . . . . . . . . . . . . . . . . 8 4.1.2.1. Secure Transport . . . . . . . . . . . . . . . . . 8
4.1.3. Error and Failure Conditions . . . . . . . . . . . . . 8 4.1.2.2. Gaming Prevention . . . . . . . . . . . . . . . . 8
4.1.3.1. Overload Condition . . . . . . . . . . . . . . . . 8 4.1.3. Error and Failure Conditions . . . . . . . . . . . . . 9
4.1.3.2. Insufficient Resources . . . . . . . . . . . . . . 8 4.1.3.1. Overload Condition . . . . . . . . . . . . . . . . 9
4.1.3.3. Unavailable and Deleted Data . . . . . . . . . . . 9 4.1.3.2. Insufficient Resources . . . . . . . . . . . . . . 9
4.1.3.4. Insufficient Permissions . . . . . . . . . . . . . 9 4.1.3.3. Unavailable and Deleted Data . . . . . . . . . . . 10
4.1.3.5. Redirection . . . . . . . . . . . . . . . . . . . 9 4.1.3.4. Insufficient Permissions . . . . . . . . . . . . . 10
4.2. Transfer and Latency Requirements . . . . . . . . . . . . 9 4.1.3.5. Redirection . . . . . . . . . . . . . . . . . . . 10
4.2.1. Low-Latency Access . . . . . . . . . . . . . . . . . . 9 4.2. Transfer Requirements . . . . . . . . . . . . . . . . . . 11
4.2.2. Data Object Size . . . . . . . . . . . . . . . . . . . 10 4.2.1. Data Object Size . . . . . . . . . . . . . . . . . . . 11
4.2.3. Communication among DECADE Servers . . . . . . . . . . 10
4.3. Data Access Requirements . . . . . . . . . . . . . . . . . 11 4.3. Data Access Requirements . . . . . . . . . . . . . . . . . 11
4.3.1. Reading/Writing Own Storage . . . . . . . . . . . . . 11 4.3.1. Reading/Writing Own Storage . . . . . . . . . . . . . 11
4.3.2. Access by Other Users . . . . . . . . . . . . . . . . 11 4.3.2. Access by Remote Clients . . . . . . . . . . . . . . . 11
4.3.3. Negotiable Data Transport Protocol . . . . . . . . . . 11 4.3.3. Negotiable Data Transport Protocol . . . . . . . . . . 12
4.3.4. Separation of Data and Control Policies . . . . . . . 12 4.3.4. Separation of Data and Control Policies . . . . . . . 12
4.4. Data Management Requirements . . . . . . . . . . . . . . . 12 4.4. Data Management Requirements . . . . . . . . . . . . . . . 12
4.4.1. Agnostic of reliability . . . . . . . . . . . . . . . 12 4.4.1. Agnostic of reliability . . . . . . . . . . . . . . . 12
4.4.2. Data Object Attributes . . . . . . . . . . . . . . . . 12 4.4.2. Data Object Attributes . . . . . . . . . . . . . . . . 13
4.4.3. Time-to-live for Written Data Objects . . . . . . . . 13 4.4.3. Time-to-live for Written Data Objects . . . . . . . . 13
4.4.4. Offline Usage . . . . . . . . . . . . . . . . . . . . 13 4.4.4. Application-defined Properties and Metadata . . . . . 13
4.5. Data Naming Requirements . . . . . . . . . . . . . . . . . 13 4.4.5. Offline Usage . . . . . . . . . . . . . . . . . . . . 14
4.5.1. Unique Names . . . . . . . . . . . . . . . . . . . . . 13 4.5. Data Naming Requirements . . . . . . . . . . . . . . . . . 14
4.6. Resource Control . . . . . . . . . . . . . . . . . . . . . 14 4.5.1. Unique Names . . . . . . . . . . . . . . . . . . . . . 14
4.6.1. Multiple Applications . . . . . . . . . . . . . . . . 14 4.6. Resource Control . . . . . . . . . . . . . . . . . . . . . 15
4.6.2. Per-Remote-Client, Per-Data Control . . . . . . . . . 14 4.6.1. Multiple Applications . . . . . . . . . . . . . . . . 15
4.6.3. Server Involvement . . . . . . . . . . . . . . . . . . 15 4.6.2. Per-Remote-Client, Per-Data Control . . . . . . . . . 15
4.7. Authorization . . . . . . . . . . . . . . . . . . . . . . 15 4.6.3. Resource Control Set . . . . . . . . . . . . . . . . . 16
4.7.1. Per-Remote-Client, Per-Data Read Access . . . . . . . 15 4.6.4. Server Involvement . . . . . . . . . . . . . . . . . . 16
4.7.2. Per-User Write Access . . . . . . . . . . . . . . . . 15 4.7. Authorization . . . . . . . . . . . . . . . . . . . . . . 16
4.7.3. Default Access Permissions . . . . . . . . . . . . . . 16 4.7.1. Per-Remote-Client, Per-Data Read Access . . . . . . . 16
4.7.4. Authorization Checks . . . . . . . . . . . . . . . . . 16 4.7.2. Per-User Write Access . . . . . . . . . . . . . . . . 17
4.7.5. Cryptographic Credentials . . . . . . . . . . . . . . 16 4.7.3. Default Access Permissions . . . . . . . . . . . . . . 17
4.7.6. Server Involvement . . . . . . . . . . . . . . . . . . 16 4.7.4. Authorization Checks . . . . . . . . . . . . . . . . . 17
4.7.7. Protocol Reuse . . . . . . . . . . . . . . . . . . . . 17 4.7.5. Cryptographic Credentials . . . . . . . . . . . . . . 17
4.8. Non-Requirements . . . . . . . . . . . . . . . . . . . . . 17 4.7.6. Server Involvement . . . . . . . . . . . . . . . . . . 18
4.8.1. Application-defined Properties and Metadata . . . . . 17 4.7.7. Protocol Reuse . . . . . . . . . . . . . . . . . . . . 18
5. Storage Requirements . . . . . . . . . . . . . . . . . . . . . 18
5. Storage Requirements . . . . . . . . . . . . . . . . . . . . . 17 5.1. Immutable Data . . . . . . . . . . . . . . . . . . . . . . 18
5.1. Immutable Data . . . . . . . . . . . . . . . . . . . . . . 17 5.2. Explicit Deletion of Data . . . . . . . . . . . . . . . . 19
5.2. Explicit Deletion of Data . . . . . . . . . . . . . . . . 18 5.3. Multiple writing . . . . . . . . . . . . . . . . . . . . . 19
5.3. Multiple writing . . . . . . . . . . . . . . . . . . . . . 18 5.4. Multiple reading . . . . . . . . . . . . . . . . . . . . . 19
5.4. Multiple reading . . . . . . . . . . . . . . . . . . . . . 18 5.5. Reading before completely written . . . . . . . . . . . . 19
5.5. Reading before completely written . . . . . . . . . . . . 18 5.6. Writing model . . . . . . . . . . . . . . . . . . . . . . 20
5.6. Hints concerning usage of written data . . . . . . . . . . 19 5.7. Storage Status . . . . . . . . . . . . . . . . . . . . . . 20
5.7. Writing model . . . . . . . . . . . . . . . . . . . . . . 19 6. Discovery Requirements . . . . . . . . . . . . . . . . . . . . 21
5.8. Storage Status . . . . . . . . . . . . . . . . . . . . . . 19 6.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 21
6. Discovery Requirements . . . . . . . . . . . . . . . . . . . . 20 6.1.1. Support for Clients Behind NATs and Firewalls . . . . 21
6.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 20 6.1.2. Prefer Existing Protocols . . . . . . . . . . . . . . 21
6.1.1. Locating DECADE Servers . . . . . . . . . . . . . . . 20 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21
6.1.2. Support for Clients Behind NATs and Firewalls . . . . 20 7.1. Authentication and Authorization . . . . . . . . . . . . . 21
6.1.3. Prefer Existing Protocols . . . . . . . . . . . . . . 20 7.2. Encrypted Data . . . . . . . . . . . . . . . . . . . . . . 22
7. Future Considerations . . . . . . . . . . . . . . . . . . . . 21 7.3. Protection against Gaming . . . . . . . . . . . . . . . . 22
7.1. Fairness . . . . . . . . . . . . . . . . . . . . . . . . . 21 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
7.2. Removal of Duplicate Data Objects . . . . . . . . . . . . 21 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
7.3. Gaming of the Resource Control Mechanism . . . . . . . . . 21 9.1. Normative References . . . . . . . . . . . . . . . . . . . 22
8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 9.2. Informative References . . . . . . . . . . . . . . . . . . 22
8.1. Authentication and Authorization . . . . . . . . . . . . . 22
8.2. Encrypted Data . . . . . . . . . . . . . . . . . . . . . . 22
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
10.1. Normative References . . . . . . . . . . . . . . . . . . . 22
10.2. Informative References . . . . . . . . . . . . . . . . . . 22
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 23 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
The object of DECoupled Application Data Enroute (DECADE) is to The object of the DECoupled Application Data Enroute (DECADE) system
provide an open and standard in-network storage system for content is to provide an open and standard in-network storage for content
distribution applications, where data is typically broken into one or distribution applications, where data is typically broken into one 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 (Internet
Protocol Television), and VoD (Video on Demand). (For a precise Protocol Television), and VoD (Video on Demand). (For a precise
definition of the applications targeted in DECADE, see the definition definition of the applications targeted in DECADE system, see the
for Target Application in Section 2.) Instead of always transferring definition for Target Application in Section 2.) Instead of always
data directly from a source/owner client to a requesting client, the transferring data directly from a source/owner client to a requesting
source/owner client can write to and manage its content on its in- client, the source/owner client can write to and manage its content
network storage. The requesting client can get the address of the on its in-network storage. The requesting client can get the address
in-network storage pertaining to the source/owner client and read of the in-network storage pertaining to the source/owner client and
data from the storage. 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
system. As such, it DOES NOT include general guiding principles. DECADE-compatible system. As such, it does not include general
General design considerations, explanation of the problem being guiding principles. General design considerations, explanation of
addressed, and enumeration of the types of applications to which the problem being addressed, and enumeration of the types of
DECADE may be suited is not considered in this document. For general applications to which a DECADE-compatible system may be suited is not
information, please see the problem statement considered in this document. For general information, please see
[I-D.ietf-decade-problem-statement] and architecture [I-D.ietf-decade-problem-statement] and [I-D.ietf-decade-arch].
[I-D.ietf-decade-arch] 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
writing, reading, and managing data, but also controlling access for writing, reading, and managing data, but also controlling access for
particular remote clients with which it is sharing data. particular remote clients with which it is sharing data.
Additionally, we also consider controlling the resources used by Additionally, we also consider controlling the resources used by
remote clients when they access data as an integral part of utilizing remote clients when they access data as an integral part of utilizing
the network storage. the network storage.
This document discusses requirements pertaining to DECADE This document discusses requirements pertaining to DECADE-compatible
protocol(s). In certain deployments, several logical in-network protocol(s). In certain deployments, several logical in-network
storage systems could be deployed (e.g., within the same storage systems could be deployed (e.g., within the same
administrative domain). These in-network storage systems can administrative domain). These in-network storage systems can
communicate and transfer data through internal or non-standard communicate and transfer data through internal or non-standard
communication messages that are outside of the scope of these communication messages that are outside of the scope of these
requirements, but they SHOULD use DECADE protocol(s) when requirements, but they should use DECADE-compatible protocol(s) when
communicating with other DECADE-capable in-network storage systems. communicating with other DECADE-compatible in-network storage
systems.
2. Terminology and Concepts 2. Terminology and Concepts
This document uses terms defined in This document uses the term 'In-network storage' which is defined in
[I-D.ietf-decade-problem-statement]. [I-D.ietf-decade-problem-statement].
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 content 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, and hybrid P2P/CDN architectures. cooperate, such as with P2P, CDN, and hybrid P2P/CDN architectures.
Such applications distribute large amounts of content (e.g., a large Such applications distribute large amounts of content (e.g., a large
file, or video stream) by dividing the content into smaller blocks file, or video stream) by dividing the content into smaller blocks
for more flexible distribution (e.g., over multiple application-level for more flexible distribution (e.g., over multiple application-level
paths). The distributed content is typically immutable (though it paths). The distributed content is immutable (though it may be
may be deleted). We use the term Target Application to refer to the deleted and replaced). We use the term Target Application to refer
type of applications that are explicitly (but not exclusively) to the type of applications that are explicitly (but not exclusively)
supported by DECADE. 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.
3. Requirements Structure 3. Requirements Structure
The DECADE protocol is intended to sit between Target Applications A DECADE-compatible protocol is intended to sit between Target
and a back-end storage system. DECADE does not intend to develop yet Applications and a storage system. This document does not intend to
another storage system, but rather to create a protocol that enables develop yet another storage system or a new protocol, but rather to
Target Applications to make use of storage within the network, explore the requirements for the DECADE protocols, either existing
leaving specific storage system considerations to the implementation ones or a potential new one, and storage system to enable Target
of the DECADE servers as much as possible. For this reason, we have 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: divided the requirements into two primary 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 combination of existing protocols and new protocols. be met by a combination of existing protocols and new protocols.
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 underlying data transport used by DECADE. In should be met by the underlying data transport used by DECADE
this document, we use "data transport" to refer to a protocol used system. In this document, we use "data transport" to refer to a
to read and write data from DECADE in-network storage. protocol used to read and write data from in-network storage.
Note that a third category also enumerates requirements on the
protocol used to discover DECADE Servers.
It should also be made clear that the approach is to make DECADE a
simple protocol, while still enabling its usage within many Target
Applications. For this reason, and to further reinforce the
distinction between DECADE and a storage system, in some cases we
also highlight the non-requirements of the protocol. These non-
requirements are intended to capture behaviors that will NOT be
assumed to be needed by DECADE's Target Applications and hence not
present in the DECADE protocol.
Finally, some implementation considerations are provided, which while This specification discusses the requirements of functionality
not strictly requirements, are intended to provide guidance and implemented with a storage system and within applications, to permit
highlight potential points that need to be considered by the protocol interoperable communications concerning the manipulation of stored
developers, and later by implementors. content.
4. Protocol Requirements 4. Protocol Requirements
This section details the requirements of DECADE protocol(s). 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. Overall Protocol Requirements
4.1.1. Connectivity Concerns 4.1.1. Connectivity Concerns
4.1.1.1. NATs and Firewalls 4.1.1.1. NATs and Firewalls
REQUIREMENT(S): DECADE client to server protocols SHOULD be usable REQUIREMENT(S): DECADE-compatible protocol(s) MUST be usable across
across firewalls and NAT (Network Address Translation) devices firewalls and NAT (Network Address Translation) devices. DECADE
without requiring additional network support (e.g., Application- protocol MUST NOT pass literal IP addresses in messages.
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 (Internet Service Provider) and Enterprise networks both in ISP (Internet Service Provider) and Enterprise networks
and by consumers. Deployment of DECADE must not require and by consumers. Deployment of a DECADE-compatible system must
modifications to such devices (beyond, perhaps, reconfiguration). not require modifications to such devices (beyond, perhaps,
Note that this requirement applies to both any new protocol reconfiguration). This requirement applies to both potential new
developed by the DECADE Working Group and any data transport used protocol that may be developed by the DECADE Working Group and
with DECADE. any data transport used with DECADE protocol.
4.1.1.2. Connections to Clients 4.1.1.2. Connections to Clients
REQUIREMENT(S): DECADE SHOULD require that network connections be REQUIREMENT(S): Network connections between DECADE-compatible client
made from DECADE clients to DECADE servers (i.e., not from the and DECADE-compatible server MUST be initiated by the client
server to the DECADE client). (i.e., the server must not initiate a connection with the
client).
RATIONALE: Many household networks and operating systems have RATIONALE: Many household networks and operating systems have
firewalls and NATs configured by default to block incoming firewalls and NATs configured by default to block incoming
connections. To ease deployment by avoiding configuration connections. To ease deployment by avoiding configuration
changes and help mitigate security risks, DECADE should not changes and help mitigate security risks, a DECADE-compatible
require clients to listen for any incoming network connections client must not be required to listen for any incoming network
(beyond what is required by any other already-deployed connections (beyond what is required by any other already-
application). deployed application).
4.1.2. Security 4.1.2. Security
4.1.2.1. Secure Transport 4.1.2.1. Secure Transport
REQUIREMENT(S): DECADE MUST contain a mode in which all REQUIREMENT(S): A secure transport MUST be implemented for all
communication between a DECADE client and server is over a secure communications between a DECADE-compatible client and DECADE-
transport that provides confidentiality, integrity, and compatible server.
authentication.
RATIONALE: Target Applications may wish to write 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, the communication between a DECADE-
communication between a DECADE client and server occurs over a compatible client and DECADE-compatible server must be
secure transport protocol (e.g., SSL/TLS). transported over a secure transport protocol (e.g., SSL/TLS).
4.1.2.2. Gaming Prevention
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. Error and Failure Conditions
4.1.3.1. Overload Condition 4.1.3.1. Overload Condition
REQUIREMENT(S): In-network storage, which is operating close to its REQUIREMENT(S): A DECADE-compatible server, which is operating close
capacity limit (e.g., too busy servicing other requests), MUST be to its capacity limit (e.g., too busy servicing other requests),
permitted to reject requests and not be required to generate MUST be permitted to reject requests and not be required to
responses to additional requests. In-network storage MUST also generate response to additional requests. A DECADE-compatible
be permitted to redirect requests (see Section 4.1.3.5) as a server MUST also be permitted to redirect requests (see Section
load-shedding technique. 4.1.3.5) as a load- shedding technique.
RATIONALE: Forcing the in-network storage to respond to requests RATIONALE: Forcing a DECADE-compatible server to respond to requests
when operating close to its capacity can impair its ability to when operating close to its capacity can impair its ability to
service existing requests, and thus is permitted to avoid service existing requests, and thus is permitted to avoid
generating responses to additional requests. generating response to additional requests.
4.1.3.2. Insufficient Resources 4.1.3.2. Insufficient Resources
REQUIREMENT(S): DECADE MUST support an error condition indicating to REQUIREMENT(S): A DECADE-compatible server SHOULD be able to provide
a DECADE client that resources (e.g., storage space) were not an error condition indicating to a DECADE-compatible client that
available to service a request (e.g., storage quota exceeded when resources (e.g., storage space) were not available to service a
attempting to write data). request (e.g., storage quota exceeded when 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 may not be locally-discoverable. In order to allocate
network interfaces, etc) are not directly attached. In order to resources appropriately amongst remote clients, a DECADE-
allocate resources appropriately amongst remote clients, a client compatible client must be able to determine when resource limits
must be able to determine when resource limits have been reached. have been reached. The DECADE-compatible client can then respond
The client can then respond by explicitly freeing necessary by explicitly freeing necessary resources or waiting for such
resources or waiting for such resources to be freed. 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.
4.1.3.3. Unavailable and Deleted Data 4.1.3.3. Unavailable and Deleted Data
REQUIREMENT(S): DECADE MUST support error conditions indicating that REQUIREMENT(S): A DECADE-compatible server SHOULD be able to provide
(1) data was rejected from being written, (2) deleted, or (3) error conditions indicating that (1) data was rejected from being
marked unavailable by a storage provider. written, (2) deleted, or (3) marked unavailable by a storage
provider.
RATIONALE: Storage providers may require the ability to (1) avoid RATIONALE: DECADE service providers may require the ability to (1)
storing, (2) delete, or (3) quarantine certain data that has been avoid storing, (2) delete, or (3) quarantine certain data that
identified as illegal (or otherwise prohibited). DECADE does not has been identified as illegal (or otherwise prohibited). It is
indicate how such data is identified, but applications using not specified how such data is identified, but applications
DECADE should not break if a storage provider is obligated to employing DECADE-compatible servers should not break if a storage
enforce such policies. Appropriate error conditions should be provider is obligated to enforce such policies. Appropriate
indicated to applications. 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 4.1.3.4. Insufficient Permissions
REQUIREMENT(S): DECADE MUST support error conditions indicating that REQUIREMENT(S): A DECADE-compatible server MUST be able to provide
the requesting client does not have sufficient permissions to error conditions indicating that the requesting client does not
access requested data objects. have sufficient permissions to access requested data objects.
RATIONALE: DECADE clients may request objects to which they do not RATIONALE: DECADE-compatible clients may request objects to which
have sufficent access permissions, and DECADE servers must be they do not have sufficient access permissions, and DECADE-
able to signal that this has occurred. Note that access compatible servers must be able to signal that this has occurred.
permissions may be insufficient due to a combination of the Access permissions may be insufficient due to a combination of
credentials presented by a client as well as additional policies the credentials presented by a client as well as additional
defined by the storage provider. policies defined by the storage provider.
4.1.3.5. Redirection 4.1.3.5. Redirection
REQUIREMENT(S): DECADE SHOULD support the ability for a DECADE REQUIREMENT(S): A DECADE-compatible server SHOULD be able to
server to redirect requests to another DECADE server. This may redirect requests to another DECADE-compatible server. This may
either be in response to an error, failure, or overload either be in response to an error, failure, or overload
condition, or to support capabilities such as load balancing. condition, or to support capabilities such as load balancing.
RATIONALE: A DECADE server may opt to redirect requests to another RATIONALE: A DECADE-compatible server may opt to redirect requests
server to support capabilities such as load balancing, or if the to another server to support capabilities such as load balancing,
implementation decides that another DECADE server is in a better or if the implementation decides that another DECADE-compatible
position to handle the request due to either its location in the server is in a better position to handle the request due to
network, server status, or other consideration. either its location in the network, server status, or other
consideration.
4.2. Transfer and Latency Requirements
4.2.1. Low-Latency Access EXCEPTION: A DECADE-compatible server can be configured by its
REQUIREMENT(S): DECADE SHOULD provide "low-latency" access for service provider to support or not support redirection
application clients. DECADE MUST allow clients to specify at functionality.
least two classes of services: lowest possible latency and
latency non-critical.
RATIONALE: Some applications may have requirements on delivery time 4.2. Transfer Requirements
(e.g., live streaming [PPLive]). The user experience may be
unsatisfactory if the use of in-network storage results in lower
performance than connecting directly to remote clients over a
low-speed, possibly congested uplink. Additionally, the overhead
required for control-plane operations in DECADE must not cause
the latency to be higher than for a low-speed, possibly congested
uplink. While it is impossible to make a guarantee that a system
using in-network storage will always outperform a system that
does not for every transfer, the overall performance of the
system should be improved compared with direct low-speed uplink
connections, even considering control overhead.
4.2.2. Data Object Size 4.2.1. Data Object Size
REQUIREMENT(S): DECADE MUST allow for efficient data transfer of REQUIREMENT(S): DECADE-compatible protocol(s) MUST allow for
small objects (e.g., 16KB) between a DECADE client and in-network efficient data transfer of small objects (e.g., 16KB) between a
storage with minimal additional latency imposed by the protocol. 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 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, clients may be
may have requirements on delivery time (e.g., in a live-streaming sensitive to the delivery time of chunks (e.g., in a live-
application). DECADE must enable data to be efficiently streaming application). DECADE-compatible protocol(s) must
transferred amongst clients at this granularity. It is important enable data to be efficiently transferred amongst DECADE-
to note that DECADE may be used to store and retrieve larger compatible clients at this granularity.
objects, but protocol(s) should not be designed such that usage
with smaller data objects cannot meet the requirements of Target
Applications.
4.2.3. Communication among DECADE Servers
REQUIREMENT(S): DECADE SHOULD support the ability for two in-network
storage elements in different administrative domains to write
and/or read data directly between each other (if authorized as
described in Section 4.7). If such a capability is supported,
this MAY be the same (or a subset or extension of) as the DECADE
protocol(s) used by clients to access data.
RATIONALE: Allowing server-to-server communication can reduce
latency in some common scenarios. Consider a scenario when a
DECADE client is downloading data into its own storage from
another client's in-network storage. One possibility is for the
client to first download the data itself, and then upload it to
its own storage. However, this uploading causes unnecessary
latency and network traffic. Allowing the data to be downloaded
from the remote in-network storage into the client's own in-
network storage can alleviate both.
4.3. Data Access Requirements 4.3. Data Access Requirements
4.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-compatible protocol(s) MUST enable a DECADE-
to read data from and write data to its own in-network storage. 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 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-compatible client can read data from
data to in-network storage space that it owns. and write data to in-network storage space that it owns.
4.3.2. Access by Other Users 4.3.2. Access by Remote Clients
REQUIREMENT(S): DECADE MUST support the ability for a user to apply REQUIREMENT(S): A DECADE-compatible client MUST be able to apply
access control policies to users other than itself for its access control policies to remote DECADE-compatible clients other
storage. The users with whom access is being shared can be under than itself for its storage. The remote DECADE-compatible
a different administrative domain than the user who owns the in- clients with whom access is being shared can be under a different
network storage. The authorized users may read from or write to administrative domain than the DECADE-compatible client who owns
the user's storage. the in-network 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 implement useful by Target Applications, a DECADE-compatible client must be
access control policies for users that may or may not be known to able to specify access control policies for remote DECADE-
the user's storage provider. compatible clients that may or may not be known to the client's
own DECADE service provider.
4.3.3. Negotiable Data Transport Protocol 4.3.3. Negotiable Data Transport Protocol
REQUIREMENT(S): DECADE MUST support the ability for a DECADE client REQUIREMENT(S): DECADE-compatible client MUST be able to negotiate
to negotiate with its in-network storage about which protocol it with DECADE server about which protocol it can use to read data
can use to read data from and write data to its In-network from and write data to its in-network storage. DECADE system
storage. DECADE MUST specify at least one mandatory protocol to MUST specify at least one mandatory protocol to be supported by
be supported by implementations; usage of a different protocol implementations; usage of a different protocol may be selected
may be selected via negotiation. 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 to define such operations in a
operations in a new protocol. However, because of the particular new DECADE 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.3.4). and Data Operations (Section 4.3.4).
4.3.4. Separation of Data and Control Policies 4.3.4. Separation of Data and Control Policies
REQUIREMENT(S): DECADE Protocol(s) MUST only provide a minimal set REQUIREMENT(S): DECADE-compatible protocol(s) MUST provide a minimal
of core operations to support diverse policies implemented and set of core operations to support diverse policies implemented
desired by Target Applications. and desired by Target Applications, and MAY provide additional
operations.
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.,
read, write). 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) is required to be supported by DECADE-
DECADE. compatible protocol(s).
4.4. Data Management Requirements 4.4. Data Management Requirements
4.4.1. Agnostic of reliability 4.4.1. Agnostic of reliability
REQUIREMENT(S): DECADE SHOULD remain agnostic of reliability/ REQUIREMENT(S): DECADE-compatible protocol(s) MUST remain agnostic
fault-tolerance level offered by storage provider. of reliability/ fault-tolerance level offered by DECADE service
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 DECADE-compatible client must be able to use multiple
DECADE services with differing levels of service. DECADE services with differing levels of service.
4.4.2. Data Object Attributes 4.4.2. Data Object Attributes
REQUIREMENT(S): DECADE MUST support the ability to associate REQUIREMENT(S): DECADE-compatible protocol(s) MUST support the
attributes with data objects with a scope local to a DECADE ability to associate attributes with data objects with a scope
server, and for DECADE clients to query these attributes. DECADE local to a DECADE-compatible server, and for DECADE-compatible
protocol(s) MUST transmit any attributes using an operating clients to query these attributes. DECADE-compatible protocol(s)
system-independent and architecture-independent standard format. MUST transmit any attributes using an operating system-
DECADE protocol(s) MUST be designed such that new attributes can independent and architecture-independent standard format. If
be added by later protocol revisions or extensions. 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: DECADE supports associating attributes (e.g., a time-to- RATIONALE: A DECADE-compatible client can associate attributes
live, creation timestamp, or object size) with a data object. (e.g., a time-to- live, creation timestamp, or object size) with
These attributes are local to a data object stored by a a data object. These attributes are local to a data object
particular DECADE server, and are thus not applied to any DECADE stored by a particular DECADE-compatible server, and are thus not
server or client to which the data object is copied. These applied to any DECADE-compatible server or client to which the
attributes may be used as hints to the storage system, internal data object is copied. These attributes may be used as hints to
optimizations, or as additional information queryable by DECADE the storage system, internal optimizations, or as additional
clients. information query-able by DECADE-compatible clients.
4.4.3. Time-to-live for Written Data Objects 4.4.3. Time-to-live for Written Data Objects
REQUIREMENT(S): DECADE MUST support the ability for a DECADE client REQUIREMENT(S): A DECADE-compatible client MUST be able to indicate
to indicate a time-to-live value (or expiration time) indicating a time-to- live value (or expiration time) indicating a length of
a length of time until particular data can be deleted by the in- time until particular data can be deleted by a DECADE-compatible
network storage element. server.
RATIONALE: Some data objects written by a DECADE client may be RATIONALE: Some data objects written by a DECADE-compatible client
usable only within a certain window of time, such as in live- may be usable only within a certain window of time, such as in
streaming P2P applications. Providing a time-to-live value for live- streaming P2P applications. Providing a time-to-live value
data objects (e.g., at the time they are written) can reduce for data objects (e.g., at the time they are written) can reduce
management overhead by avoiding many 'delete' commands sent to management overhead by avoiding many 'delete' commands sent to
in-network storage. The in-network storage may still keep the DECADE-compatible server. The in-network storage may still keep
data in cache for bandwidth optimization. But this is guided by the data in cache for bandwidth optimization. But this is guided
the privacy policy of the DECADE provider. by the privacy policy of the DECADE service provider.
4.4.4. Offline Usage 4.4.4. Application-defined Properties and Metadata
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.
REQUIREMENT(S): DECADE MAY support the ability for a user to provide RATIONALE: Associating key-value pairs that are defined by Target
authorized access to its in-network storage even if the user has Applications with data objects introduces substantial complexity
no DECADE applications actively running or connected to the to the protocol(s). If Target Applications wish to associate
network. 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 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.5. Data Naming Requirements 4.5. Data Naming Requirements
4.5.1. Unique Names 4.5.1. Unique Names
REQUIREMENT(S): DECADE MUST support a naming scheme that ensures a REQUIREMENT(S): DECADE-compatible protocol(s) MUST support a data
high probability of uniqueness and supports the operation of object naming scheme that ensures a high probability of
DECADE servers under diverse administrative domains with no uniqueness and supports the operation of DECADE-compatible
coordination. DECADE SHOULD provide a mechanism (minimally servers under diverse administrative domains with no
rejection) to handle the improbable case of a collision. 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 Client should be RATIONALE: When writing a data object, a DECADE-compatible Client
able to write it without being concerned over whether an object should be able to write it without being concerned over whether
of the same name already exists, unless the existing object an object of the same name already exists, unless the existing
contains the exact same data. Note that it may be reasonable for object contains the exact same data. Although the intention is
DECADE to satisfy this requirement probabilistically (e.g., using to avoid name collision, it's not absolutely zero possibility.
a hashing mechanism). As a result, it is wise to provide a As a result, it is required to provide a collision handling
collision handling mechanism, even if the probability of mechanism.
collisions is extremely low.
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. Resource Control
4.6.1. Multiple Applications 4.6.1. Multiple Applications
REQUIREMENT(S): DECADE SHOULD support the ability for users to REQUIREMENT(S): A DECADE-compatible client MUST be able to indicate
define resource sharing policies for multiple applications to a DECADE-compatible server about resource sharing policies for
(DECADE clients) being run/managed by the user. multiple target applications being run/managed by the same 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 target applications.
example, the user may run one or more video-on-demand For example, the user may run one or more video-on-demand
application(s) and a live-streaming application(s) which both application(s) and a live-streaming application(s) which both
make use of the user's in-network storage. The applications may make use of the user's in-network storage. The applications may
be running on different machines and may not directly be running on different machines and may not directly
communicate. Thus, DECADE should enable the user to determine communicate. Thus, user should be able to determine resource
resource sharing policies between the applications. sharing policies between 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 within DECADE protocol(s) to identify individual passing values within DECADE-compatible protocol(s) to identify
applications. Such identifiers can be either user-generated or individual applications. Such identifiers can be either user-
server-generated and do not need to be registered by IANA. generated or server-generated and do not need to be registered by
IANA.
4.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-compatible client MUST be able to assign
policies (bandwidth share, storage quota, and network connection resource policies (bandwidth share, storage quota, and network
quota) to individual remote clients for reading from and writing connection quota) to individual remote clients for reading from
particular data to its in-network storage within a particular and writing particular data to its in-network storage within a
range of time. The DECADE server MUST enforce these constraints. particular range of time.
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,
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 less than 100MB of data in total. Since
client may need to manage multiple clients accessing its data, it the client may need to manage multiple clients accessing its
should be able to indicate the time over which the granted data, it should be able to indicate the time over which the
resources are usable. For example, an expiration time for the granted resources are usable. For example, an expiration time
access could be indicated to the server after which no resources for the access could be indicated to the DECADE-compatible server
are granted (e.g., indicate error as access denied). after which no resources are granted (e.g., indicate error as
access denied).
4.6.3. Server Involvement 4.6.3. Resource Control Set
REQUIREMENT(S): A DECADE client SHOULD be able to indicate to a REQUIREMENT(S): DECADE-compatible protocol(s) MUST define a minimum
DECADE server, without itself contacting the server, resource set of resource control methods, and MAY add additional set of
control policies for remote clients' requests. resource control methods.
RATIONALE: One important consideration for in-network storage RATIONALE: The minimum set of resource control methods need to
elements is scalability, since a single storage element may be include the most common resource control methods. Implementors
used to support many users. Many Target Applications use small can add proprietary set of resource control methods in their own
chunk sizes and frequent data exchanges. If such an application implementation.
employed resource control and contacted the in-network storage
element for each data exchange, this could present a scalability 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 challenge for the server as well as additional latency for
clients. clients.
Our preferred alternative is to let requesting users obtain The preferred way is to let requesting clients obtain signed
signed resource control policies (in the form of a token) from resource control policies (in the form of a token) from the
the owning user, and then users can then present the policy to owning client, and then requesting clients can present the policy
the storage directly. This can result in reduced messaging to a DECADE-compatible server directly. This can result in
handled by the in-network storage. reduced messaging handled by the DECADE-compatible server.
4.7. Authorization 4.7. Authorization
4.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-compatible Client MUST be able to control
individual remote clients are authorized to read particular data which individual remote clients are authorized to read particular
from its in-network storage. data 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.
be able to circumvent such decisions by arbitrarily reading any
data in in-network storage.
4.7.2. Per-User Write Access 4.7.2. Per-User Write Access
REQUIREMENT(S): A DECADE Client MUST be able to control which
individual remote clients are authorized to write data into its REQUIREMENT(S): A DECADE-compatible Client MUST be able to control
in-network storage. 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 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-compatible client should be able to
certain remote clients this privilege. grant only certain remote clients this privilege.
4.7.3. Default Access Permissions 4.7.3. Default Access Permissions
REQUIREMENT(S): Unless read or write access is granted by a DECADE REQUIREMENT(S): Unless read or write access is granted by a DECADE
Client to a remote client, the default access MUST be no access. Client to a remote client, the default access MUST be no access.
RATIONALE: The current leading proposal for an access control model RATIONALE: The current leading proposal for an access control model
in DECADE is via token passing, resulting in a system with little in DECADE working group is via token passing, resulting in a
state on the server side. system with little state on the server side.
4.7.4. Authorization Checks 4.7.4. Authorization Checks
REQUIREMENT(S): In-network storage MUST check the authorization of a REQUIREMENT(S): A DECADE-compatible server MUST check the
client before it executes a supplied request. The in-network authorization of a client before it executes a supplied request.
storage MAY use optimizations to avoid such authorization checks
as long as the enforced permissions are the same.
RATIONALE: Authorization granted by a DECADE client are meaningless RATIONALE: The data stored at a DECADE-compatible server is assumed
unless unauthorized requests are denied access. Thus, the in- to be private, and thus not accessible to a DECADE-enabled client
network storage element must verify the authorization of a unless it is explicitly granted permission.
particular request before it is executed.
4.7.5. Cryptographic Credentials 4.7.5. Cryptographic Credentials
REQUIREMENT(S): Access MUST be able to be granted using REQUIREMENT(S): Access MUST be able to be granted using
cryptographic credentials. cryptographic credentials.
RATIONALE: DECADE clients may be operating on hosts without constant RATIONALE: DECADE-compatible clients may be operating on hosts
network connectivity or without a permanent attachment address without constant network connectivity or without a permanent
(e.g., mobile devices). To support access control with such attachment address (e.g., mobile devices). To support access
hosts, DECADE servers must support access control policies that control with such hosts, DECADE-compatible servers must support
use cryptographic credentials, not simply by tying access to IP access control policies that use cryptographic credentials, not
addresses. simply by tying access to IP addresses.
4.7.6. Server Involvement 4.7.6. Server Involvement
REQUIREMENT(S): A DECADE client SHOULD be able to indicate, without
contacting the server itself, access control policies for remote
clients' requests.
RATIONALE: See discussion in Section 4.6.3. 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 4.7.7. Protocol Reuse
REQUIREMENT(S): If possible, DECADE SHOULD reuse existing protocol REQUIREMENT(S): DECADE SHOULD reuse existing protocol and mechanisms
and mechanisms for Authentication, Access, and Authorization for Authentication, Access, and Authorization (AAA). No new AAA
(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 RATIONALE: If possible, reusing an existing AAA protocol/mechanism
will minimize the development required by applications, and will will minimize the development required by applications, and will
maximize interoperability of the DECADE protocol with existing maximize interoperability of the DECADE-compatible protocol(s)
infrastructure. with existing infrastructure.
4.8. Non-Requirements
4.8.1. Application-defined Properties and Metadata
REQUIREMENT(S): DECADE MUST NOT provide a mechanism for associating
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 DECADE protocol. 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 server.
5. Storage Requirements 5. Storage Requirements
This section details the requirements of the underlying storage used This section details the requirements of the underlying storage used
to support the DECADE protocol(s). to support DECADE-compatible protocol(s).
5.1. Immutable Data 5.1. Immutable Data
REQUIREMENT(S): DECADE MUST only store and manage data objects that REQUIREMENT(S): The data objects MUST be immutable once they are
are immutable once they are written to storage. written to storage.
RATIONALE: Immutable data objects are an important simplification in RATIONALE: Immutable data objects are an important simplification in
DECADE. Reasonable consistency models for updating existing DECADE-compatible system. Reasonable consistency models for
objects would significantly complicate implementation (especially updating existing objects would significantly complicate
if implementation chooses to replicate data across multiple implementation (especially if implementation chooses to replicate
servers). If a user needs to update a resource, it can write a data across multiple servers). If the content owners have to
new resource and then distribute the new resource instead of the modify the written data objects, there are many ways to do so.
old one. 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.
5.2. Explicit Deletion of Data 5.2. Explicit Deletion of Data
REQUIREMENT(S): DECADE MUST support the ability for a DECADE client REQUIREMENT(S): A DECADE-compatible client MUST be able to
to explicitly delete data from its own in-network storage. explicitly delete data from its own in-network storage.
RATIONALE: A DECADE client may continually be writing data to its RATIONALE: A DECADE-compatible client may continually be writing
in-network storage. Since there may be a limit (e.g., imposed by data to its in-network storage. Since there may be a limit
the storage provider) to how much total storage can be used, some (e.g., imposed by the storage provider) to how much total storage
data may need to be removed to make room for additional data. A can be used, some data may need to be removed to make room for
DECADE client should be able to explicitly remove particular additional data. A DECADE-compatible client should be able to
data. This may be implemented using existing protocols. explicitly remove particular data. This may be implemented using
existing protocols.
5.3. Multiple writing 5.3. Multiple writing
REQUIREMENT(S): DECADE MUST NOT allow multiple simultaneous writers REQUIREMENT(S): A DECADE-compatible server MUST NOT allow multiple
for the same object. Implementations MUST raise an error to one simultaneous writers for the same object. A DECADE-compatible
of the writers. 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 RATIONALE: This avoids data corruption in a simple way while
remaining efficient. Alternately, the DECADE server would need remaining efficient. Alternately, the DECADE-compatible server
to either manage locking, handle write collisions, or merge data, would need to either manage locking, handle write collisions, or
all of which reduce efficiency and increase complexity. 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 5.4. Multiple reading
REQUIREMENT(S): DECADE MUST allow for multiple simultaneous readers REQUIREMENT(S): A DECADE-compatible server MUST allow for multiple
for an object. simultaneous readers 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-compatible server to allow multiple readers to read the
concurrently. content concurrently.
5.5. Reading before completely written 5.5. Reading before completely written
REQUIREMENT(S): DECADE MAY allow readers to read from objects before REQUIREMENT(S): A DECADE-compatible server MAY allow readers to read
they have been completely written. 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.
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 written). 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.
5.6. Hints concerning usage of written data 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
REQUIREMENT(S): DECADE MAY allow writers of new objects to indicate generate a response.
specific hints concerning how the objects are expected to be used
(e.g., access frequency or time-to-live).
RATIONALE: Different Target Applications may have different usage
patterns for objects written to in-network storage. For example,
a P2P live streaming application may indicate to a DECADE server
that the objects are expected to have a short time-to-live, but
read frequently. The DECADE server may then opt to persist the
objects in memory instead of in disk.
5.7. Writing model 5.6. Writing model
REQUIREMENT(S): DECADE storage MUST provide at least a writing model REQUIREMENT(S): A DECADE-compatible server MUST provide at least a
(while writing an object) that appends data to data already writing model (while writing an object) that appends data to data
written. 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-compatible server in multiple packets. To keep
simple, the DECADE must at least support the ability to write the implementation simple, the DECADE-compatible server must at least
data sequentially in the order received. Implementations MAY support the ability to write the data sequentially in the order
allow application to write data in an object out-of-order (but received. Implementations MAY allow application to write data in
MUST NOT overwrite ranges of the object that have already been an object out-of-order (but MUST NOT overwrite ranges of the
written). object that have already been written).
5.8. Storage Status 5.7. Storage Status
REQUIREMENT(S): A DECADE client MUST be able to read current REQUIREMENT(S): A DECADE-compatible server MUST be able to respond
resource usage (including list of written data objects), resource resource usage and resource quotas. A minimum set of storage
quotas, and access permissions for its in-network storage. The status supported by DECADE-compatible server MUST include
returned information MUST include resource usage resulting from resource usage resulting from the client's own usage (including
the client's own usage and usage by other clients that have been list of written data objects) and usage by other clients that
authorized to read/write objects or open connections to that have been authorized to read/write objects on that client's
client's storage. DECADE protocol(s) MUST support the ability storage. A DECADE-compatible server MUST be able to authenticate
for a DECADE client to read aggregated resource usage information the request.
(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 necessarily
(e.g., disk, network interface, etc). Thus, the client cannot directly-attached (e.g., disk, network interface, etc). Thus,
locally determine how such resources are being used. Before the client cannot locally determine how such resources are being
storing and retrieving data, a client should be able to determine used. Before storing and retrieving data, a client should be
which data is available (e.g., after an application restart). able to determine which data is available (e.g., after an
Additionally, a client should be able to determine resource application restart).
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. Discovery Requirements 6. Discovery Requirements
6.1. Requirements 6.1. Requirements
6.1.1. Locating DECADE Servers 6.1.1. Support for Clients Behind NATs and Firewalls
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 criteria, it may still read/write data
from/to a DECADE Server if authorized by another DECADE Client.
6.1.2. Support for Clients Behind NATs and Firewalls
REQUIREMENT(S): The Discovery mechanism MUST support DECADE Clients REQUIREMENT(S): The mechanism for discovering a DECADE-compatible
operating behind NATs and Firewalls without requiring additional server MUST be operable by DECADE-compatible clients operating
network support (e.g., Application-level Gateways). behind NATs and Firewalls.
RATIONALE: NATs and Firewalls are prevalent in network deployments, RATIONALE: NATs and Firewalls are prevalent in network deployments,
and it is common for Target Applications that include a DECADE and it is common for Target Applications that include a DECADE-
Client to be deployed behind these devices. compatible client to be deployed behind these devices.
6.1.3. Prefer Existing Protocols 6.1.2. Prefer Existing Protocols
REQUIREMENT(S): The DECADE Server discovery mechanism SHOULD REQUIREMENT(S): The mechanism for discovering a DECADE-compatible
leverage existing mechanisms and protocols wherever possible. 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. RATIONALE: Existing protocols such as DNS and DHCP are widespread.
Using existing protocols, or combinations of the protocols that Using existing protocols, or combinations of the protocols that
have been specified in other contexts, is strictly preferred over have been specified in other contexts, is strictly preferred over
developing a new discovery protocol for DECADE. developing a new discovery protocol.
7. Future Considerations
This section enumerates considerations that should be taken into
account during the DECADE design and implementation. They have been
intentionally omitted as requirements since they are either out of
scope or implementation-dependent. Nevertheless, enumerating them
may help to guide future application of the requirements included in
this document.
7.1. Fairness
To provide fairness among users, the in-network storage provider
should assign resource (e.g., storage, bandwidth, connections) quota
for users. This can prevent a small number of clients from occupying
large amounts of resources on the in-network storage, while others
starve.
7.2. Removal of Duplicate Data Objects
There are actually two possible scenarios. The first is the case of
removing duplicates within one particular DECADE server (or logical
server). While not a requirement, as it does not impact the
protocol, a DECADE server may implement internal mechanisms to
monitor for duplicate objects and use internal mechanisms to prevent
duplication in internal storage.
The second scenario is removing duplicates across a distributed set
of DECADE servers. DECADE does not explicitly design for this, but
does offer a redirection mechanism (Section 4.1.3.5) that is one
primitive that may be used to support this feature in certain
deployment scenarios.
7.3. Gaming of the Resource Control Mechanism 7. Security Considerations
The particular resource control policy communicated by a DECADE The security model is an important component of a DECADE-compatible
protocol and enforced by the scheduling system of a DECADE system. It is crucial for users to be able to manage and limit
implementation may be open to certain gaming by clients. for example distribution of content to only authorized parties, and the mechanism
by specifying many small peers to increase total throughput or needs to work on the general Internet which spans multiple
inciting overload conditions at a DECADE server. Identifying and administrative and security domains. Previous sections have
protecting against all such opportunities for gaming is outside the enumerated detailed requirements, but this section discusses the
scope of this document, but DECADE protocol(s) and implementations overall approach and other considerations that do not merit
SHOULD be aware that opportunities to game the system may be requirements.
attempted.
8. Security Considerations 7.1. Authentication and Authorization
The security model is an important component of DECADE. It is A DECADE-compatible server must authenticate any DECADE-compatible
crucial for users to be able to manage and limit distribution of client that attempts to access the in-network storage. DECADE-
content to only authorized parties, and the mechanism needs to work compatible server is not involved in the authorization between DECADE
on the general Internet which spans multiple administrative and clients and remote clients, or the authorization between DECADE
security domains. Previous sections have enumerated detailed system user and DECADE service provider. In order to authenticate an
requirements, but this section discusses the overall approach and accessing DECADE client, a DECADE-compatible server may need to
other considerations that do not merit requirements. accept the authentication and authorization referral by another
DECADE-compatible client.
8.1. Authentication and Authorization 7.2. Encrypted Data
DECADE only uses authentication when allowing a particular client to DECADE-compatible Servers provide the ability to write raw data
access its own storage at a server. DECADE servers themselves do not objects (subject to any policies instituted by the owner/
authenticate other clients which are reading/writing a client's own administrator of the service provider). Thus, DECADE-compatible
storage. Instead, DECADE relies on clients to authenticate others to clients may opt to encrypt data before it is transported to the
access its storage, and then communicate the result of that server. However, DECADE-compatible protocol(s) do not provide
authentication to the DECADE server so that the DECADE server may encryption of data objects other than that provided by
implement the necessary authorization checks. Section 4.1.2.1.
8.2. Encrypted Data 7.3. Protection against Gaming
DECADE Servers provide the ability to write raw data objects (subject The particular resource control policy communicated by DECADE-
to any policies instituted by the owner/administrator of the DECADE compatible protocol(s) and enforced on DECADE-compatible server may
server, which are outside of the scope of this document). Thus, be open to certain gaming by clients. For example by specifying many
DECADE clients may opt to encrypt data before it is written to the small chunks to increase total throughput or inciting overload
DECADE Server. However, DECADE itself does not provide encryption of conditions are techniques that may be used by a client.
data objects other than is provided by Section 4.1.2.1.
9. IANA Considerations 8. IANA Considerations
There are no IANA considerations with this document. There are no IANA considerations with this document.
10. References 9. References
10.1. Normative References 9.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.
10.2. Informative References
[I-D.ietf-decade-problem-statement] [I-D.ietf-decade-problem-statement]
Song, H., 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-03 (work in progress), draft-ietf-decade-problem-statement-03 (work in progress),
March 2011. March 2011.
9.2. Informative References
[I-D.ietf-decade-arch] [I-D.ietf-decade-arch]
Alimi, R., Yang, Y., Rahman, A., Kutscher, D., and H. Liu, Alimi, R., Yang, Y., Rahman, A., Kutscher, D., and H. Liu,
"DECADE Architecture", draft-ietf-decade-arch-02 (work in "DECADE Architecture", draft-ietf-decade-arch-02 (work in
progress), July 2011. progress), July 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>.
 End of changes. 130 change blocks. 
587 lines changed or deleted 559 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/