draft-ietf-decade-reqs-03.txt   draft-ietf-decade-reqs-04.txt 
DECADE Y. Gu DECADE Y. Gu
Internet-Draft Huawei Internet-Draft Huawei
Intended status: Informational D. Bryan Intended status: Informational D. Bryan
Expires: January 12, 2012 Polycom, Inc. Expires: March 31, 2012 Polycom, Inc.
Y. Yang Y. Yang
Yale University Yale University
R. Alimi R. Alimi
Google Google
July 11, 2011 September 28, 2011
DECADE Requirements DECADE Requirements
draft-ietf-decade-reqs-03 draft-ietf-decade-reqs-04
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 (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 store and retrieve, 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 system.
These are requirements on the entire system; some of the requirements These are requirements on the entire system; some of the requirements
may eventually be implemented by an existing protocol with/without may eventually be implemented by an existing protocol with/without
some extensions (e.g., a protocol used to read and write data from some extensions (e.g., a protocol used to read and write data from
the storage system). A user of DECADE as a complete architecture the storage system). The requirements in this document are intended
would be guaranteed complete functionality. to ensure that the DECADE 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 to IETF in full conformance with the
skipping to change at page 2, line 12 skipping to change at page 2, line 13
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 January 12, 2012. This Internet-Draft will expire on March 31, 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 12 skipping to change at page 3, line 12
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. Overall Protocol Requirements . . . . . . . . . . . . . . 7 4.1. Overall Protocol Requirements . . . . . . . . . . . . . . 7
4.1.1. Metadata and Cross-platform Access . . . . . . . . . . 7 4.1.1. Connectivity Concerns . . . . . . . . . . . . . . . . 7
4.1.2. Connectivity Concerns . . . . . . . . . . . . . . . . 7 4.1.1.1. NATs and Firewalls . . . . . . . . . . . . . . . . 7
4.1.2.1. NATs and Firewalls . . . . . . . . . . . . . . . . 7 4.1.1.2. Connections to Clients . . . . . . . . . . . . . . 7
4.1.2.2. Connections to Clients . . . . . . . . . . . . . . 8 4.1.2. Security . . . . . . . . . . . . . . . . . . . . . . . 7
4.1.3. Security . . . . . . . . . . . . . . . . . . . . . . . 8 4.1.2.1. Secure Transport . . . . . . . . . . . . . . . . . 7
4.1.3.1. Secure Transport . . . . . . . . . . . . . . . . . 8 4.1.3. Error and Failure Conditions . . . . . . . . . . . . . 8
4.1.4. Error and Failure Conditions . . . . . . . . . . . . . 8 4.1.3.1. Overload Condition . . . . . . . . . . . . . . . . 8
4.1.4.1. Overload Condition . . . . . . . . . . . . . . . . 8 4.1.3.2. Insufficient Resources . . . . . . . . . . . . . . 8
4.1.4.2. Insufficient Resources . . . . . . . . . . . . . . 8 4.1.3.3. Unavailable and Deleted Data . . . . . . . . . . . 8
4.1.4.3. Unavailable and Deleted Data . . . . . . . . . . . 9 4.1.3.4. Insufficient Permissions . . . . . . . . . . . . . 9
4.1.4.4. Redirection . . . . . . . . . . . . . . . . . . . 9 4.1.3.5. Redirection . . . . . . . . . . . . . . . . . . . 9
4.2. Transfer and Latency Requirements . . . . . . . . . . . . 9 4.2. Transfer and Latency Requirements . . . . . . . . . . . . 9
4.2.1. Low-Latency Access . . . . . . . . . . . . . . . . . . 9 4.2.1. Low-Latency Access . . . . . . . . . . . . . . . . . . 9
4.2.2. Data Object Size . . . . . . . . . . . . . . . . . . . 10 4.2.2. Data Object Size . . . . . . . . . . . . . . . . . . . 10
4.2.3. Communication among DECADE Servers . . . . . . . . . . 10 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 Other Users . . . . . . . . . . . . . . . . 11
4.3.3. Negotiable Data Transport Protocol . . . . . . . . . . 11 4.3.3. Negotiable Data Transport Protocol . . . . . . . . . . 11
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. Time-to-live for Written Data Objects . . . . . . . . 12 4.4.2. Data Object Attributes . . . . . . . . . . . . . . . . 12
4.4.3. Offline Usage . . . . . . . . . . . . . . . . . . . . 13 4.4.3. Time-to-live for Written Data Objects . . . . . . . . 13
4.4.4. Offline Usage . . . . . . . . . . . . . . . . . . . . 13
4.5. Data Naming Requirements . . . . . . . . . . . . . . . . . 13 4.5. Data Naming Requirements . . . . . . . . . . . . . . . . . 13
4.5.1. Unique Names . . . . . . . . . . . . . . . . . . . . . 13 4.5.1. Unique Names . . . . . . . . . . . . . . . . . . . . . 13
4.6. Resource Control . . . . . . . . . . . . . . . . . . . . . 13 4.6. Resource Control . . . . . . . . . . . . . . . . . . . . . 14
4.6.1. Multiple Applications . . . . . . . . . . . . . . . . 13 4.6.1. Multiple Applications . . . . . . . . . . . . . . . . 14
4.6.2. Per-Remote-Client, Per-Data Control . . . . . . . . . 14 4.6.2. Per-Remote-Client, Per-Data Control . . . . . . . . . 14
4.6.3. Server Involvement . . . . . . . . . . . . . . . . . . 14 4.6.3. Server Involvement . . . . . . . . . . . . . . . . . . 15
4.7. Authorization . . . . . . . . . . . . . . . . . . . . . . 15 4.7. Authorization . . . . . . . . . . . . . . . . . . . . . . 15
4.7.1. Per-Remote-Client, Per-Data Read Access . . . . . . . 15 4.7.1. Per-Remote-Client, Per-Data Read Access . . . . . . . 15
4.7.2. Per-User Write Access . . . . . . . . . . . . . . . . 15 4.7.2. Per-User Write Access . . . . . . . . . . . . . . . . 15
4.7.3. Default Access Permissions . . . . . . . . . . . . . . 15 4.7.3. Default Access Permissions . . . . . . . . . . . . . . 16
4.7.4. Authorization Checks . . . . . . . . . . . . . . . . . 15 4.7.4. Authorization Checks . . . . . . . . . . . . . . . . . 16
4.7.5. Cryptographic Credentials . . . . . . . . . . . . . . 16 4.7.5. Cryptographic Credentials . . . . . . . . . . . . . . 16
4.7.6. Server Involvement . . . . . . . . . . . . . . . . . . 16 4.7.6. Server Involvement . . . . . . . . . . . . . . . . . . 16
4.7.7. Protocol Reuse . . . . . . . . . . . . . . . . . . . . 16 4.7.7. Protocol Reuse . . . . . . . . . . . . . . . . . . . . 16
5. Storage Requirements . . . . . . . . . . . . . . . . . . . . . 16 4.8. Non-Requirements . . . . . . . . . . . . . . . . . . . . . 17
5.1. Immutable Data . . . . . . . . . . . . . . . . . . . . . . 16 4.8.1. Application-defined Properties and Metadata . . . . . 17
5. Storage Requirements . . . . . . . . . . . . . . . . . . . . . 17
5.1. Immutable Data . . . . . . . . . . . . . . . . . . . . . . 17
5.2. Explicit Deletion of Data . . . . . . . . . . . . . . . . 17 5.2. Explicit Deletion of Data . . . . . . . . . . . . . . . . 17
5.3. Multiple writing . . . . . . . . . . . . . . . . . . . . . 17 5.3. Multiple writing . . . . . . . . . . . . . . . . . . . . . 18
5.4. Multiple reading . . . . . . . . . . . . . . . . . . . . . 17 5.4. Multiple reading . . . . . . . . . . . . . . . . . . . . . 18
5.5. Reading before completely written . . . . . . . . . . . . 18 5.5. Reading before completely written . . . . . . . . . . . . 18
5.6. Hints concerning usage of written data . . . . . . . . . . 18 5.6. Hints concerning usage of written data . . . . . . . . . . 18
5.7. Writing model . . . . . . . . . . . . . . . . . . . . . . 18 5.7. Writing model . . . . . . . . . . . . . . . . . . . . . . 19
5.8. Storage Status . . . . . . . . . . . . . . . . . . . . . . 18 5.8. Storage Status . . . . . . . . . . . . . . . . . . . . . . 19
6. Discovery Requirements . . . . . . . . . . . . . . . . . . . . 19 6. Discovery Requirements . . . . . . . . . . . . . . . . . . . . 20
6.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 19 6.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 20
6.1.1. Locating DECADE Servers . . . . . . . . . . . . . . . 19 6.1.1. Locating DECADE Servers . . . . . . . . . . . . . . . 20
6.1.2. Support for Clients Behind NATs and Firewalls . . . . 19 6.1.2. Support for Clients Behind NATs and Firewalls . . . . 20
6.1.3. Prefer Existing Protocols . . . . . . . . . . . . . . 20 6.1.3. Prefer Existing Protocols . . . . . . . . . . . . . . 20
7. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 20 7. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 20
7.1. Non-IAP Internal Protocols . . . . . . . . . . . . . . . . 20 7.1. Non-DECADE Internal Protocols . . . . . . . . . . . . . . 20
7.2. Fairness . . . . . . . . . . . . . . . . . . . . . . . . . 20 7.2. Fairness . . . . . . . . . . . . . . . . . . . . . . . . . 21
7.3. Removal of Duplicate Data Objects . . . . . . . . . . . . 20 7.3. Removal of Duplicate Data Objects . . . . . . . . . . . . 21
7.4. Gaming of the Resource Control Mechanism . . . . . . . . . 21 7.4. Gaming of the Resource Control Mechanism . . . . . . . . . 21
8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21
8.1. Authentication and Authorization . . . . . . . . . . . . . 21 8.1. Authentication and Authorization . . . . . . . . . . . . . 22
8.2. Encrypted Data . . . . . . . . . . . . . . . . . . . . . . 21 8.2. Encrypted Data . . . . . . . . . . . . . . . . . . . . . . 22
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
10.1. Normative References . . . . . . . . . . . . . . . . . . . 22 10.1. Normative References . . . . . . . . . . . . . . . . . . . 22
10.2. Informative References . . . . . . . . . . . . . . . . . . 22 10.2. Informative References . . . . . . . . . . . . . . . . . . 22
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 22 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
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 content provide an open and standard in-network storage system for content
distribution applications, where data is typically broken in to one distribution applications, where data is typically broken into 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 (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, see the definition
for Target Application in Section 2.) Instead of always transferring for Target Application in Section 2.) Instead of always transferring
data directly from a source/owner client to a requesting client, the data directly from a source/owner client to a requesting client, the
source/owner client can write to and manage its content on its in- source/owner client can write to and manage its content on its in-
network storage. The requesting client can get the address of the network storage. The requesting client can get the address of the
in-network storage pertaining to the source/owner client and read in-network storage pertaining to the source/owner client and read
data from the storage. 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 principles. 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
[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.
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].
the In-network storage Access Protocol, which is the protocol used to
communicate between a DECADE client and DECADE server (in-network
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 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 (peer-to-peer) / CDN (Content cooperate, such as with P2P, CDN, and hybrid P2P/CDN architectures.
Distribution Network) hybrid architectures. Such applications Such applications distribute large amounts of content (e.g., a large
distribute large amounts of content (e.g., a large file, or video file, or video stream) by dividing the content into smaller blocks
stream) by dividing the content into smaller blocks for more flexible for more flexible distribution (e.g., over multiple application-level
distribution (e.g., over multiple application-level paths). The paths). The distributed content is typically immutable (though it
distributed content is typically immutable (though it may be may be deleted). We use the term Target Application to refer to the
deleted). We use the term Target Application to refer to the type of type of applications that are explicitly (but not exclusively)
applications that are explicitly (but not exclusively) supported by supported by DECADE.
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. DECADE does not intend to develop yet and a back-end storage system. DECADE does not intend to develop yet
another storage system, but rather to create a protocol that enables another storage system, but rather to create a protocol that enables
Target Applications to make use of storage within the network, Target Applications to make use of storage within the network,
leaving specific storage system considerations to the implementation leaving specific storage system considerations to the implementation
of the DECADE servers as much as possible. For this reason, we have of the DECADE 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 new protocol to be defined within the DECADE Working be met by a combination of existing protocols and new protocols to
Group. be defined within the DECADE Working 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 underlying data transport used by DECADE. In should be met by the underlying data transport used by DECADE. In
this document, we use "data transport" to refer to a protocol used this document, we use "data transport" to refer to a protocol used
to read and write data from DECADE in-network storage. to read and write data from DECADE in-network storage.
Note that a third category also enumerates requirements on the Note that a third category also enumerates requirements on the
protocol used to discovery DECADE Servers. protocol used to discover 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
not strictly requirements, are intended to provide guidance and not strictly requirements, are intended to provide guidance and
highlight potential points that need to be considered by the protocol highlight potential points that need to be considered by the protocol
developers, and later by implementors. developers, and later by implementors.
4. Protocol Requirements 4. Protocol Requirements
This section details the requirements of the DECADE IAP. This section details the requirements of DECADE protocol(s).
4.1. Overall Protocol Requirements 4.1. Overall Protocol Requirements
4.1.1. Metadata and Cross-platform Access 4.1.1. Connectivity Concerns
REQUIREMENT(S): If DECADE supports the ability to associate metadata
with data objects, the DECADE protocol(s) MUST transmit any
metadata using an operating system-independent and architecture-
independent standard format.
RATIONALE: If DECADE supports storing metadata (e.g., a description,
uploaded date, object size), a possible use for the metadata is
to help a DECADE client locate a desired data object. Data
objects may be written by DECADE clients running on various
platforms. To enable metadata to be readable regardless of its
source it must be transmitted to and from the DECADE server in a
standard format.
4.1.2. Connectivity Concerns
4.1.2.1. NATs and Firewalls 4.1.1.1. NATs and Firewalls
REQUIREMENT(S): DECADE SHOULD be usable across firewalls and NAT REQUIREMENT(S): DECADE SHOULD be usable across firewalls and NAT
(Network Address Translation) devices without requiring (Network Address Translation) devices without requiring
additional network support (e.g., Application-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 (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 DECADE must not require
modifications to such devices (beyond, perhaps, reconfiguration). modifications to such devices (beyond, perhaps, reconfiguration).
Note that this requirement applies to both any new protocol Note that this requirement applies to both any new protocol
developed by the DECADE Working Group and any data transport used developed by the DECADE Working Group and any data transport used
with DECADE. with DECADE.
4.1.2.2. Connections to Clients 4.1.1.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 from the made from DECADE clients to DECADE servers (i.e., not from the
server to 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 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, DECADE should not
require clients to listen for any incoming network connections require clients to listen for any incoming network connections
(beyond what is required by any other already-deployed (beyond what is required by any other already-deployed
application). application).
4.1.3. Security 4.1.2. Security
4.1.3.1. Secure Transport
4.1.2.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 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, 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.4. Error and Failure Conditions 4.1.3. Error and Failure Conditions
4.1.4.1. Overload Condition 4.1.3.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 permitted to reject requests and not be required to generate
to additional requests. responses to additional requests. In-network storage MUST also
be permitted to redirect requests (see Section 4.1.3.5) as a
load-shedding technique.
RATIONALE: Forcing the in-network storage to respond to requests RATIONALE: Forcing the in-network storage 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 responses to additional requests.
4.1.4.2. Insufficient Resources 4.1.3.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 write 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.4.3. Unavailable and Deleted Data 4.1.3.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 written, (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.4.4. Redirection 4.1.3.4. Insufficient Permissions
REQUIREMENT(S): DECADE MUST support error conditions indicating that
the requesting client does not have sufficient permissions to
access requested data objects.
RATIONALE: DECADE clients may request objects to which they do not
have sufficent access permissions, and DECADE servers must be
able to signal that this has occurred. Note that access
permissions may be insufficient due to a combination of the
credentials presented by a client as well as additional policies
defined by the storage provider.
4.1.3.5. Redirection
REQUIREMENT(S): 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 either be in response to an error, failure, or overload
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 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.2. Transfer and Latency Requirements 4.2. Transfer and Latency Requirements
4.2.1. Low-Latency Access 4.2.1. Low-Latency Access
skipping to change at page 10, line 34 skipping to change at page 10, line 24
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 imposed 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. It is important
to note that DECADE may be used to store and retrieve larger
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 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 write storage elements in different administrative domains to write
and/or read data directly between each other (if authorized as and/or read data directly between each other (if authorized as
described in Section 4.7). If such a capability is supported, described in Section 4.7). If such a capability is supported,
this MAY be the same (or a subset or extension of) as the IAP this MAY be the same (or a subset or extension of) as the DECADE
used by clients to access data. protocol(s) 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 uploading causes unnecessary
network traffic. Allowing the data to be downloaded from the latency and network traffic. Allowing the data to be downloaded
remote in-network storage into the client's own in-network from the remote in-network storage into the client's own in-
storage can alleviate both. 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 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
skipping to change at page 12, line 7 skipping to change at page 12, line 7
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.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): The DECADE IAP MUST only provide a minimal set of REQUIREMENT(S): DECADE Protocol(s) MUST only provide a minimal set
core operations to support diverse policies implemented and of 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.,
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) may be required to be directly specified by
skipping to change at page 12, line 33 skipping to change at page 12, line 33
4.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.4.2. Time-to-live for Written Data Objects 4.4.2. Data Object Attributes
REQUIREMENT(S): DECADE MUST support the ability to associate
attributes with data objects with a scope local to a DECADE
server, and for DECADE clients to query these attributes. DECADE
protocol(s) MUST transmit any attributes using an operating
system-independent and architecture-independent standard format.
DECADE protocol(s) 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-
live, creation timestamp, or object size) with a data object.
These attributes are local to a data object stored by a
particular DECADE server, and are thus not applied to any DECADE
server or client to which the data object is copied. These
attributes may be used as hints to the storage system, internal
optimizations, or as additional information queryable by DECADE
clients.
4.4.3. 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 objects written by a DECADE client may be RATIONALE: Some data objects written by a DECADE client may be
usable only within a certain window of time, such as in live- usable only within a certain window of time, such as in live-
streaming P2P applications. Providing a time-to-live value for streaming P2P applications. Providing a time-to-live value for
data objects (e.g., at the time they are written) can reduce 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 in-network storage. The in-network storage may still keep the
data in cache for bandwidth optimization. But this is guided by data in cache for bandwidth optimization. But this is guided by
the privacy policy of the DECADE provider. the privacy policy of the DECADE provider.
4.4.3. Offline Usage 4.4.4. 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.5. Data Naming Requirements 4.5. Data Naming Requirements
4.5.1. Unique Names 4.5.1. Unique Names
REQUIREMENT(S): DECADE MUST use a naming scheme with an extremely REQUIREMENT(S): DECADE MUST support a naming scheme that ensures a
large namespace and mechanisms that ensure that the name of a high probability of uniqueness and supports the operation of
data object is statistically unlikely to be the same as the names DECADE servers under diverse administrative domains with no
of all other data objects (globally) with different content. coordination. DECADE SHOULD provide a mechanism (minimally
DECADE SHOULD provide a mechanism (minimally rejection) to handle rejection) to handle the improbable case of a collision.
the improbable case of a collision.
RATIONALE: When writing a data object, a DECADE Client should be RATIONALE: When writing a data object, a DECADE Client should be
able to write 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). As a result, it is wise to provide a a hashing mechanism). As a result, it is wise to provide a
collision handling mechanism, even if the probability of collision handling mechanism, even if the probability of
collisions is extremely low. collisions is extremely low.
skipping to change at page 14, line 9 skipping to change at page 14, line 25
example, the user may run one or more video-on-demand 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, DECADE should enable the user to determine
resource sharing policies between the applications. resource 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 over IAP to identify individual applications. passing values within DECADE protocol(s) to identify individual
Such identifiers can be either user-generated or server-generated applications. Such identifiers can be either user-generated or
and do not need to be registered by IANA. 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 client MUST be able to assign resource
policies (bandwidth share, storage quota, and network connection policies (bandwidth share, storage quota, and network connection
quota) to individual remote clients for reading from and writing 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
skipping to change at page 15, line 5 skipping to change at page 15, line 20
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 Our preferred alternative is to let requesting users obtain
control policies (in the form of a token) from the owning user, signed resource control policies (in the form of a token) from
and then users can then present the policy to the storage the owning user, and then users can then present the policy to
directly. This can result in reduced messaging handled by the the storage directly. This can result in reduced messaging
in-network storage. handled by the in-network storage.
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 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
from 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-
skipping to change at page 16, line 41 skipping to change at page 17, line 10
REQUIREMENT(S): If possible, DECADE SHOULD reuse existing protocol REQUIREMENT(S): If possible, DECADE SHOULD reuse existing protocol
and mechanisms for Authentication, Access, and Authorization and mechanisms for Authentication, Access, and Authorization
(AAA). (AAA).
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 protocol with existing
infrastructure. 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 IAP. to support the DECADE protocol(s).
5.1. Immutable Data 5.1. Immutable Data
REQUIREMENT(S): DECADE MUST provide the ability to manage data REQUIREMENT(S): DECADE MUST provide the ability to manage data
objects that are immutable once they are written to storage. objects that are immutable once they are 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. Reasonable consistency models for updating existing
objects would significantly complicate implementation (especially objects would significantly complicate implementation (especially
if implementation chooses to replicate data across multiple if implementation chooses to replicate data across multiple
servers). If a user needs to update a resource, it can write a servers). If a user needs to update a resource, it can write a
new resource and then distribute the new resource instead of the new resource and then distribute the new resource instead of the
old one. old one.
skipping to change at page 18, line 21 skipping to change at page 18, line 49
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 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 written to 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 short time-to-live, but
read frequently. The DECADE server may then opt to persist 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.
5.7. Writing model 5.7. Writing model
REQUIREMENT(S): DECADE storage MUST provide at least a writing model REQUIREMENT(S): DECADE storage MUST provide at least a writing model
(while writing an object) that appends data to data already (while writing an object) that appends data to data already
written. 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
skipping to change at page 20, line 6 skipping to change at page 20, line 33
Server that fits these criteria, it may still read/write data a Server that fits these criteria, it may still read/write data a
DECADE Server if authorized by another DECADE Client. DECADE Server if authorized by another DECADE Client.
6.1.2. Support for Clients Behind NATs and Firewalls 6.1.2. Support for Clients Behind NATs and Firewalls
REQUIREMENT(S): The Discovery mechanism MUST support DECADE Clients REQUIREMENT(S): The Discovery mechanism MUST support DECADE Clients
operating behind NATs and Firewalls without requiring additional operating behind NATs and Firewalls without requiring additional
network support (e.g., Application-level Gateways). network support (e.g., Application-level Gateways).
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 wishing to include a and it is common for Target Applications that include a DECADE
DECADE Client to be deployed behind these devices. Client to be deployed behind these devices.
6.1.3. Prefer Existing Protocols 6.1.3. Prefer Existing Protocols
REQUIREMENT(S): The DECADE Server discovery mechanism SHOULD prefer REQUIREMENT(S): The DECADE Server discovery mechanism SHOULD
to use existing mechanisms and protocols wherever possible. leverage existing mechanisms and protocols wherever possible.
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 for DECADE.
7. Discussion 7. Discussion
7.1. Non-IAP Internal Protocols 7.1. Non-DECADE Internal Protocols
Sometimes, several logical in-network storage systems could be Sometimes, several logical in-network storage systems could be
deployed on the same physical network device. In this case, in- deployed on the same physical network device. In this case, in-
network storages on the same physical network device can communicate network storages on the same physical network device can communicate
and transfer data through internal communication messages. However and transfer data through internal communication messages. However
in-network storages deployed on different physical network devices in-network storages deployed on different physical network devices
SHOULD communicate with in-network storage Access Protocol (IAP). SHOULD communicate with DECADE protocol(s).
7.2. Fairness 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.
7.3. Removal of Duplicate Data Objects 7.3. Removal of Duplicate Data Objects
There are actually two possible scenarios. The first is the case of There are actually two possible scenarios. The first is the case of
removing duplicates within one particular DECADE server (or logical removing duplicates within one particular DECADE server (or logical
server). While not a requirement, as it does not impact the server). While not a requirement, as it does not impact the
protocol, a DECADE server may implement internal mechanisms to protocol, a DECADE server may implement internal mechanisms to
monitor for duplicate objects and use internal mechanisms to prevent monitor for duplicate objects and use internal mechanisms to prevent
duplication in internal storage. duplication in internal storage.
The second scenario is removing duplicates across a distributed set The second scenario is removing duplicates across a distributed set
of DECADE servers. DECADE does not explicitly design for this, but of DECADE servers. DECADE does not explicitly design for this, but
does offer a redirection mechanism (Section 4.1.4.4) that is one does offer a redirection mechanism (Section 4.1.3.5) that is one
primitive that may be used to support this feature in certain primitive that may be used to support this feature in certain
deployment scenarios. deployment scenarios.
7.4. Gaming of the Resource Control Mechanism 7.4. Gaming of the Resource Control Mechanism
The particular resource control policy communicated by a DECADE The particular resource control policy communicated by a DECADE
protocol and enforced by the scheduling system of a DECADE protocol and enforced by the scheduling system of a DECADE
implementation may be open to certain gaming by clients. for example implementation may be open to certain gaming by clients. for example
by specifying many small peers to increase total throughput or by specifying many small peers to increase total throughput or
inciting overload conditions at a DECADE server. Identifying and inciting overload conditions at a DECADE server. Identifying and
protecting against all such opportunities for gaming is outside the protecting against all such opportunities for gaming is outside the
scope of this document, but DECADE protocol(s) and implementations scope of this document, but DECADE protocol(s) and implementations
SHOULD be aware that opportunities ti game the system may be SHOULD be aware that opportunities to game the system may be
attempted. attempted.
8. Security Considerations 8. Security Considerations
The security model is an important component of DECADE. It is The security model is an important component of DECADE. It is
crucial for users to be able to manage and limit distribution of crucial for users to be able to manage and limit distribution of
content to only authorized parties, and the mechanism needs to work content to only authorized parties, and the mechanism needs to work
on the general Internet which spans multiple administrative and on the general Internet which spans multiple administrative and
security domains. Previous sections have enumerated detailed security domains. Previous sections have enumerated detailed
requirements, but this section discusses the overall approach and requirements, but this section discusses the overall approach and
skipping to change at page 21, line 40 skipping to change at page 22, line 20
access its own storage at a server. DECADE servers themselves do not access its own storage at a server. DECADE servers themselves do not
authenticate other clients which are reading/writing a client's own authenticate other clients which are reading/writing a client's own
storage. Instead, DECADE relies on clients to authenticate others to storage. Instead, DECADE relies on clients to authenticate others to
access its storage, and then communicate the result of that access its storage, and then communicate the result of that
authentication to the DECADE server so that the DECADE server may authentication to the DECADE server so that the DECADE server may
implement the necessary authorization checks. implement the necessary authorization checks.
8.2. Encrypted Data 8.2. Encrypted Data
DECADE Servers provide the ability to write raw data objects (subject DECADE Servers provide the ability to write raw data objects (subject
to any policies instituted by the owner/administrator if the DECADE to any policies instituted by the owner/administrator of the DECADE
server, which are outside of the scope of this document). Thus, 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 clients may opt to encrypt data before it is written to the
DECADE Server. However, DECADE itself does not provide encryption of DECADE Server. However, DECADE itself does not provide encryption of
data objects other than is provided by Section 4.1.3.1. data objects other than is provided by Section 4.1.2.1.
9. IANA Considerations 9. IANA Considerations
There are no IANA considerations with this document. There are no IANA considerations with this document.
10. References 10. References
10.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.
10.2. Informative References 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.
[I-D.ietf-decade-arch]
Alimi, R., Yang, Y., Rahman, A., Kutscher, D., and H. Liu,
"DECADE Architecture", draft-ietf-decade-arch-02 (work in
progress), July 2011.
[LLSB08] Levin, D., LaCurts, K., Spring, N., and B. Bhattacharjee, [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
 End of changes. 60 change blocks. 
131 lines changed or deleted 178 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/