draft-ietf-decade-reqs-01.txt   draft-ietf-decade-reqs-02.txt 
DECADE Y. Gu DECADE Y. Gu
Internet-Draft Huawei Internet-Draft Huawei
Intended status: Informational D. Bryan Intended status: Informational D. Bryan
Expires: September 15, 2011 Cogent Force, LLC / Huawei Expires: November 18, 2011 Cogent Force, LLC / Huawei
Y. Yang Y. Yang
Yale University Yale University
R. Alimi R. Alimi
Google Google
March 14, 2011 May 17, 2011
DECADE Requirements DECADE Requirements
draft-ietf-decade-reqs-01 draft-ietf-decade-reqs-02
Abstract Abstract
The target of DECoupled Application Data Enroute (DECADE) is to The target of DECoupled Application Data Enroute (DECADE) is to
provide an open and standard in-network storage system for provide an open and standard in-network storage system for
applications, primarily P2P applications, to store, retrieve and applications, primarily P2P applications, to store, retrieve and
manage their data. This draft enumerates and explains requirements, manage their data. This draft enumerates and explains requirements,
not only for store and retrieve, but also for data management, access not only for store and retrieve, but also for data management, access
control and resource control, that should be considered during the control and resource control, that should be considered during the
design and implementation of a DECADE system. These are requirements design and implementation of a DECADE system. These are requirements
skipping to change at page 2, line 10 skipping to change at page 2, line 10
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 15, 2011. This Internet-Draft will expire on November 18, 2011.
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 17 skipping to change at page 3, line 17
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology and Concepts . . . . . . . . . . . . . . . . . . . 5 2. Terminology and Concepts . . . . . . . . . . . . . . . . . . . 5
3. Requirements Structure . . . . . . . . . . . . . . . . . . . . 6 3. Requirements Structure . . . . . . . . . . . . . . . . . . . . 6
4. Protocol Requirements . . . . . . . . . . . . . . . . . . . . 7 4. Protocol Requirements . . . . . . . . . . . . . . . . . . . . 7
4.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 7
4.1.1. Overall Protocol Requirements . . . . . . . . . . . . 7 4.1.1. Overall Protocol Requirements . . . . . . . . . . . . 7
4.1.1.1. Cross-platform Access . . . . . . . . . . . . . . 7 4.1.1.1. Cross-platform Access . . . . . . . . . . . . . . 7
4.1.1.2. Connectivity Concerns . . . . . . . . . . . . . . 7 4.1.1.2. Connectivity Concerns . . . . . . . . . . . . . . 7
4.1.1.2.1. NATs and Firewalls . . . . . . . . . . . . . . 7 4.1.1.2.1. NATs and Firewalls . . . . . . . . . . . . . . 7
4.1.1.2.2. Connections to Clients . . . . . . . . . . . . 7 4.1.1.2.2. Connections to Clients . . . . . . . . . . . . 7
4.1.1.3. Error and Failure Conditions . . . . . . . . . . . 8 4.1.1.3. Security . . . . . . . . . . . . . . . . . . . . . 8
4.1.1.3.1. Overload Condition . . . . . . . . . . . . . . 8 4.1.1.3.1. Secure Transport . . . . . . . . . . . . . . . 8
4.1.1.3.2. Insufficient Resources . . . . . . . . . . . . 8 4.1.1.3.2. Connections to Clients . . . . . . . . . . . . 8
4.1.1.3.3. Unavailable and Deleted Data . . . . . . . . . 8 4.1.1.4. Error and Failure Conditions . . . . . . . . . . . 8
4.1.1.3.4. Redirection . . . . . . . . . . . . . . . . . 9 4.1.1.4.1. Overload Condition . . . . . . . . . . . . . . 8
4.1.1.4.2. Insufficient Resources . . . . . . . . . . . . 8
4.1.1.4.3. Unavailable and Deleted Data . . . . . . . . . 9
4.1.1.4.4. Redirection . . . . . . . . . . . . . . . . . 9
4.1.2. Transfer and Latency Requirements . . . . . . . . . . 9 4.1.2. Transfer and Latency Requirements . . . . . . . . . . 9
4.1.2.1. Low-Latency Access . . . . . . . . . . . . . . . . 9 4.1.2.1. Low-Latency Access . . . . . . . . . . . . . . . . 9
4.1.2.2. Indirect Transfer . . . . . . . . . . . . . . . . 9 4.1.2.2. Indirect Transfer . . . . . . . . . . . . . . . . 10
4.1.2.3. Data Object Size . . . . . . . . . . . . . . . . . 10 4.1.2.3. Data Object Size . . . . . . . . . . . . . . . . . 10
4.1.2.4. Communication among In-network Storage Elements . 10 4.1.2.4. Communication among In-network Storage Elements . 10
4.1.3. Data Access Requirements . . . . . . . . . . . . . . . 10 4.1.3. Data Access Requirements . . . . . . . . . . . . . . . 11
4.1.3.1. Reading/Writing Own Storage . . . . . . . . . . . 10 4.1.3.1. Reading/Writing Own Storage . . . . . . . . . . . 11
4.1.3.2. Access by Other Users . . . . . . . . . . . . . . 10 4.1.3.2. Access by Other Users . . . . . . . . . . . . . . 11
4.1.3.3. Negotiable Data Protocol . . . . . . . . . . . . . 11 4.1.3.3. Negotiable Data Protocol . . . . . . . . . . . . . 11
4.1.3.4. Separation of Data Operations from Application 4.1.3.4. Separation of Data Operations from Application
Control . . . . . . . . . . . . . . . . . . . . . 11 Control . . . . . . . . . . . . . . . . . . . . . 12
4.1.4. Data Management Requirements . . . . . . . . . . . . . 12 4.1.4. Data Management Requirements . . . . . . . . . . . . . 12
4.1.4.1. Agnostic of reliability . . . . . . . . . . . . . 12 4.1.4.1. Agnostic of reliability . . . . . . . . . . . . . 12
4.1.4.2. Time-to-live for Stored Data . . . . . . . . . . . 12 4.1.4.2. Time-to-live for Stored Data . . . . . . . . . . . 13
4.1.4.3. Offline Usage . . . . . . . . . . . . . . . . . . 12 4.1.4.3. Offline Usage . . . . . . . . . . . . . . . . . . 13
4.1.5. Resource Control . . . . . . . . . . . . . . . . . . . 12 4.1.5. Data Naming Requirements . . . . . . . . . . . . . . . 13
4.1.5.1. Multiple Applications . . . . . . . . . . . . . . 12 4.1.5.1. Unique Names . . . . . . . . . . . . . . . . . . . 13
4.1.5.2. Per-Remote-Client, Per-Data Control . . . . . . . 13 4.1.6. Resource Control . . . . . . . . . . . . . . . . . . . 14
4.1.5.3. Server Involvement . . . . . . . . . . . . . . . . 13 4.1.6.1. Multiple Applications . . . . . . . . . . . . . . 14
4.1.6. Authorization . . . . . . . . . . . . . . . . . . . . 14 4.1.6.2. Per-Remote-Client, Per-Data Control . . . . . . . 14
4.1.6.1. Per-Remote-Client, Per-Data Read Access . . . . . 14 4.1.6.3. Server Involvement . . . . . . . . . . . . . . . . 15
4.1.6.2. Per-User Write Access . . . . . . . . . . . . . . 14 4.1.7. Authorization . . . . . . . . . . . . . . . . . . . . 15
4.1.6.3. Authorization Checks . . . . . . . . . . . . . . . 15 4.1.7.1. Per-Remote-Client, Per-Data Read Access . . . . . 15
4.1.6.4. Credentials Not IP-Based . . . . . . . . . . . . . 15 4.1.7.2. Per-User Write Access . . . . . . . . . . . . . . 15
4.1.6.5. Server Involvement . . . . . . . . . . . . . . . . 15 4.1.7.3. Authorization Checks . . . . . . . . . . . . . . . 16
5. Storage Requirements . . . . . . . . . . . . . . . . . . . . . 15 4.1.7.4. Credentials Not IP-Based . . . . . . . . . . . . . 16
5.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 15 4.1.7.5. Server Involvement . . . . . . . . . . . . . . . . 16
5.1.1. Explicit Deletion of Stored Data . . . . . . . . . . . 15 5. Discovery Requirements . . . . . . . . . . . . . . . . . . . . 16
5.1.2. Multiple writing . . . . . . . . . . . . . . . . . . . 16 5.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 16
5.1.3. Multiple reading . . . . . . . . . . . . . . . . . . . 16 5.1.1. Locating DECADE Servers . . . . . . . . . . . . . . . 17
5.1.4. Reading before completely written . . . . . . . . . . 16 5.1.2. Support for Clients Behind NATs and Firewalls . . . . 17
5.1.5. Hints concerning usage stored data . . . . . . . . . . 16 5.1.3. Prefer Existing Protocols . . . . . . . . . . . . . . 17
5.1.6. Writing model . . . . . . . . . . . . . . . . . . . . 17 6. Storage Requirements . . . . . . . . . . . . . . . . . . . . . 17
5.1.7. Storage Status . . . . . . . . . . . . . . . . . . . . 17 6.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 17
5.2. Non-Requirements . . . . . . . . . . . . . . . . . . . . . 17 6.1.1. Explicit Deletion of Stored Data . . . . . . . . . . . 17
5.2.1. No ability to update . . . . . . . . . . . . . . . . . 18 6.1.2. Multiple writing . . . . . . . . . . . . . . . . . . . 18
6. Implementation Considerations . . . . . . . . . . . . . . . . 18 6.1.3. Multiple reading . . . . . . . . . . . . . . . . . . . 18
6.1. Resource Scheduling . . . . . . . . . . . . . . . . . . . 18 6.1.4. Reading before completely written . . . . . . . . . . 18
6.2. Removal of Duplicate Records . . . . . . . . . . . . . . . 18 6.1.5. Hints concerning usage stored data . . . . . . . . . . 18
7. Discussion and Open Issues . . . . . . . . . . . . . . . . . . 19 6.1.6. Writing model . . . . . . . . . . . . . . . . . . . . 19
7.1. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 19 6.1.7. Storage Status . . . . . . . . . . . . . . . . . . . . 19
7.2. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 19 6.2. Non-Requirements . . . . . . . . . . . . . . . . . . . . . 19
8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 6.2.1. No ability to update . . . . . . . . . . . . . . . . . 20
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 7. Implementation Considerations . . . . . . . . . . . . . . . . 20
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 7.1. Resource Scheduling . . . . . . . . . . . . . . . . . . . 20
10.1. Normative References . . . . . . . . . . . . . . . . . . . 20 7.2. Removal of Duplicate Records . . . . . . . . . . . . . . . 20
10.2. Informative References . . . . . . . . . . . . . . . . . . 20 8. Discussion and Open Issues . . . . . . . . . . . . . . . . . . 21
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 20 8.1. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 8.2. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 21
9. Security Considerations . . . . . . . . . . . . . . . . . . . 22
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
11.1. Normative References . . . . . . . . . . . . . . . . . . . 22
11.2. Informative References . . . . . . . . . . . . . . . . . . 22
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 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 provide an open and standard in-network storage system for
applications, primarily applications that could be implemented using applications, primarily applications that could be implemented using
a content distribution paradigm, where data is broken in to one or a content distribution paradigm, where data is broken in to 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, and VoD. types of applications including P2P applications, IPTV, and VoD.
Instead of always transferring data directly from a source/owner Instead of always transferring data directly from a source/owner
skipping to change at page 8, line 5 skipping to change at page 8, line 5
made from DECADE clients to DECADE servers (i.e., not to the made from DECADE clients to DECADE servers (i.e., not to the
DECADE client). DECADE client).
RATIONALE: Many household networks and operating systems have RATIONALE: Many household networks and operating systems have
firewalls and NATs configured by default. To ease deployment by firewalls and NATs configured by default. To ease deployment by
avoiding configuration changes and help mitigate security risks, avoiding configuration changes and help mitigate security risks,
DECADE should not require clients to listen for any incoming DECADE should not require clients to listen for any incoming
network connections (beyond what is required by any other network connections (beyond what is required by any other
already-deployed application). already-deployed application).
4.1.1.3. Error and Failure Conditions 4.1.1.3. Security
4.1.1.3.1. Overload Condition 4.1.1.3.1. Secure Transport
REQUIREMENT(S): DECADE MUST contain a mode in which all
communication between a DECADE client and server is over a secure
transport that provides confidentiality, integrity, and
authentication.
RATIONALE: Target Applications may wish to store sensitive data. To
satisfy this use case, DECADE must provide a mode in which all
communication between a DECADE client and server occurs over a
secure transport protocol (e.g., SSL/TLS).
4.1.1.3.2. Connections to Clients
REQUIREMENT(S): DECADE SHOULD require that network connections be
made from DECADE clients to DECADE servers (i.e., not to the
DECADE client).
RATIONALE: Many household networks and operating systems have
firewalls and NATs configured by default. To ease deployment by
avoiding configuration changes and help mitigate security risks,
DECADE should not require clients to listen for any incoming
network connections (beyond what is required by any other
already-deployed application).
4.1.1.4. Error and Failure Conditions
4.1.1.4.1. Overload Condition
REQUIREMENT(S): In-network storage, which is operating close to its REQUIREMENT(S): In-network storage, which is operating close to its
capacity limit (e.g., too busy servicing other requests), MUST be capacity limit (e.g., too busy servicing other requests), MUST be
able to reject requests and not be required to generate responses able to reject requests and not be required to generate responses
to additional requests. to additional requests.
RATIONALE: When in-network storage is operating at a limit where it RATIONALE: When in-network storage is operating at a limit where it
may not be able to process additional requests, it should not be may not be able to process additional requests, it should not be
required to generate responses to such additional requests. required to generate responses to such additional requests.
Forcing the in-network storage to do so can impair its ability to Forcing the in-network storage to do so can impair its ability to
service existing requests. service existing requests.
4.1.1.3.2. Insufficient Resources 4.1.1.4.2. Insufficient Resources
REQUIREMENT(S): DECADE MUST support an error condition indicating to REQUIREMENT(S): DECADE MUST support an error condition indicating to
a DECADE client that resources (e.g., storage space) were not a DECADE client that resources (e.g., storage space) were not
available to service a request (e.g., storage quota exceeded when available to service a request (e.g., storage quota exceeded when
attempting to store data). attempting to store data).
RATIONALE: The currently-used resource levels within the in-network RATIONALE: The currently-used resource levels within the in-network
storage are not locally-discoverable, since the resources (disk, storage are not locally-discoverable, since the resources (disk,
network interfaces, etc) are not directly attached. In order to network interfaces, etc) are not directly attached. In order to
allocate resources appropriately amongst remote clients, a client allocate resources appropriately amongst remote clients, a client
must be able to determine when resource limits have been reached. must be able to determine when resource limits have been reached.
The client can then respond by explicitly freeing necessary The client can then respond by explicitly freeing necessary
resources or waiting for such resources to be freed. resources or waiting for such resources to be freed.
4.1.1.3.3. Unavailable and Deleted Data 4.1.1.4.3. Unavailable and Deleted Data
REQUIREMENT(S): DECADE MUST support error conditions indicating that REQUIREMENT(S): DECADE MUST support error conditions indicating that
(1) data was rejected from being stored, (2) deleted, or (3) (1) data was rejected from being stored, (2) deleted, or (3)
marked unavailable by a storage provider. marked unavailable by a storage provider.
RATIONALE: Storage providers may require the ability to (1) avoid RATIONALE: Storage providers may require the ability to (1) avoid
storing, (2) delete, or (3) quarantine certain data that has been storing, (2) delete, or (3) quarantine certain data that has been
identified as illegal (or otherwise prohibited). DECADE does not identified as illegal (or otherwise prohibited). DECADE does not
indicate how such data is identified, but applications using indicate how such data is identified, but applications using
DECADE should not break if a storage provider is obligated to DECADE should not break if a storage provider is obligated to
enforce such policies. Appropriate error conditions should be enforce such policies. Appropriate error conditions should be
indicated to applications. indicated to applications.
4.1.1.3.4. Redirection 4.1.1.4.4. Redirection
REQUIREMENT(S): DECADE SHOULD support the ability for a DECADE REQUIREMENT(S): DECADE SHOULD support the ability for a DECADE
server to redirect requests to another DECADE server. This may server to redirect requests to another DECADE server. This may
be in response to either an error or failure condition, or to be in response to either an error or failure condition, or to
support capabilities such as load balancing. support capabilities such as load balancing.
RATIONALE: A DECADE server may opt to redirect requests to another RATIONALE: A DECADE server may opt to redirect requests to another
server to support capabilities such as load balancing, or if the server to support capabilities such as load balancing, or if the
implementation decides that another DECADE server is in a better implementation decides that another DECADE server is in a better
position to handle the request due to either its location in the position to handle the request due to either its location in the
skipping to change at page 12, line 46 skipping to change at page 13, line 34
authorized access to its in-network storage even if the user has authorized access to its in-network storage even if the user has
no DECADE applications actively running or connected to the no DECADE applications actively running or connected to the
network. network.
RATIONALE: If an application desires, it can authorize remote RATIONALE: If an application desires, it can authorize remote
clients to access its storage even after the application exits or clients to access its storage even after the application exits or
network connectivity is lost. An example use case is mobile network connectivity is lost. An example use case is mobile
scenarios, where a client can lose and regain network scenarios, where a client can lose and regain network
connectivity very often. connectivity very often.
4.1.5. Resource Control 4.1.5. Data Naming Requirements
4.1.5.1. Unique Names
REQUIREMENT(S): DECADE SHOULD use a naming scheme in which the name
of a data object is unique from the names of all other data
objects with different content.
RATIONALE: When storing a data object, a DECADE Client should be
able to store it without being concerned over whether an object
of the same name already exists, unless the existing object
contains the exact same data. Note that it may be reasonable for
DECADE to satisfy this requirement probabilistically (e.g., using
a hashing mechanism).
4.1.6. Resource Control
4.1.6.1. Multiple Applications
4.1.5.1. Multiple Applications
REQUIREMENT(S): DECADE SHOULD support the ability for users to REQUIREMENT(S): DECADE SHOULD support the ability for users to
define resource sharing policies for multiple applications define resource sharing policies for multiple applications
(DECADE clients) being run/managed by the user. (DECADE clients) being run/managed by the user.
RATIONALE: A user may own in-network storage and share the in- RATIONALE: A user may own in-network storage and share the in-
network storage resources amongst multiple applications. For network storage resources amongst multiple applications. For
example, the user may run a video-on-demand application and a example, the user may run a video-on-demand application and a
live-streaming (or even two different live-streaming live-streaming (or even two different live-streaming
applications) application which both make use of the user's in- applications) application which both make use of the user's in-
network storage. The applications may be running on different network storage. The applications may be running on different
skipping to change at page 13, line 25 skipping to change at page 14, line 30
enable the user to determine resource sharing policies between enable the user to determine resource sharing policies between
the applications. the applications.
One possibility is for a user to indicate the particular resource One possibility is for a user to indicate the particular resource
sharing policies between applications out-of-band (not using a sharing policies between applications out-of-band (not using a
standard protocol), but this requirement may manifest itself in standard protocol), but this requirement may manifest itself in
passing values over IAP to identify individual applications. passing values over IAP to identify individual applications.
Such identifiers can be either user-generated or server-generated Such identifiers can be either user-generated or server-generated
and do not need to be registered by IANA. and do not need to be registered by IANA.
4.1.5.2. Per-Remote-Client, Per-Data Control 4.1.6.2. Per-Remote-Client, Per-Data Control
REQUIREMENT(S): A DECADE client MUST be able to assign resource REQUIREMENT(S): A DECADE client MUST be able to assign resource
quotas to individual remote clients for reading from and writing quotas to individual remote clients for reading from and writing
particular data to its in-network storage within a particular particular data to its in-network storage within a particular
range of time. The DECADE server MUST enforce these constraints. range of time. The DECADE server MUST enforce these constraints.
RATIONALE: Target Applications can rely on control of resources on a RATIONALE: Target Applications can rely on control of resources on a
per-remote-client or per-data basis. For example, application per-remote-client or per-data basis. For example, application
policy may indicate that certain remote clients have a higher policy may indicate that certain remote clients have a higher
bandwidth share for receiving data [LLSB08]. Additionally, bandwidth share for receiving data [LLSB08]. Additionally,
certain data (e.g., chunks) may be distributed with a higher certain data (e.g., chunks) may be distributed with a higher
priority. As another example, when allowing a remote client to priority. As another example, when allowing a remote client to
write data to a user's in-network storage, the remote client may write data to a user's in-network storage, the remote client may
be restricted to write only a certain amount of data. Since the be restricted to write only a certain amount of data. Since the
client may need to manage multiple clients accessing its data, it client may need to manage multiple clients accessing its data, it
should be able to indicate the time over which the granted should be able to indicate the time over which the granted
resources are usable. For example, an expiration time for the resources are usable. For example, an expiration time for the
access could be indicated to the server after which no resources access could be indicated to the server after which no resources
are granted (e.g., indicate error as access denied). are granted (e.g., indicate error as access denied).
4.1.5.3. Server Involvement 4.1.6.3. Server Involvement
REQUIREMENT(S): A DECADE client MUST be able to indicate to a DECADE
server, without itself contacting the server, resource control REQUIREMENT(S): A DECADE client SHOULD be able to indicate to a
policies for remote clients' requests. DECADE server, without itself contacting the server, resource
control policies for remote clients' requests.
RATIONALE: One important consideration for in-network storage RATIONALE: One important consideration for in-network storage
elements is scalability, since a single storage element may be elements is scalability, since a single storage element may be
used to support many users. Many Target Applications use small used to support many users. Many Target Applications use small
chunk sizes and frequent data exchanges. If such an application chunk sizes and frequent data exchanges. If such an application
employed resource control and contacted the in-network storage employed resource control and contacted the in-network storage
element for each data exchange, this could present a scalability element for each data exchange, this could present a scalability
challenge for the server as well as additional latency for challenge for the server as well as additional latency for
clients. clients.
An alternative is to let requesting users get the resource An alternative is to let requesting users obtain signed resource
control policies and users can then present the policy to the control policies from the owning user, and then users can then
storage directly. This can result in reduced messaging handled present the policy to the storage directly. This can result in
by the in-network storage. reduced messaging handled by the in-network storage.
4.1.6. Authorization 4.1.7. Authorization
4.1.6.1. Per-Remote-Client, Per-Data Read Access 4.1.7.1. Per-Remote-Client, Per-Data Read Access
REQUIREMENT(S): A DECADE Client MUST be able to control which REQUIREMENT(S): A DECADE Client MUST be able to control which
individual remote clients are authorized to read particular data individual remote clients are authorized to read particular data
stored on its in-network storage. stored on its in-network storage.
RATIONALE: A Target Application can control certain application- RATIONALE: A Target Application can control certain application-
level policies by sending particular data (e.g., chunks) to level policies by sending particular data (e.g., chunks) to
certain remote clients. It is important that remote clients not certain remote clients. It is important that remote clients not
be able to circumvent such decisions by arbitrarily reading any be able to circumvent such decisions by arbitrarily reading any
currently-stored data in in-network storage. currently-stored data in in-network storage.
4.1.6.2. Per-User Write Access 4.1.7.2. Per-User Write Access
REQUIREMENT(S): A DECADE Client MUST be able to control which REQUIREMENT(S): A DECADE Client MUST be able to control which
individual remote clients are authorized to store data into its individual remote clients are authorized to store data into its
in-network storage. in-network storage.
RATIONALE: The space managed by a user in in-network storage can be RATIONALE: The space managed by a user in in-network storage can be
a limited resource. At the same time, it can be useful to allow a limited resource. At the same time, it can be useful to allow
remote clients to write data directly to a user's in-network remote clients to write data directly to a user's in-network
storage. Thus, a DECADE client should be able to grant only storage. Thus, a DECADE client should be able to grant only
certain remote clients this privilege. certain remote clients this privilege.
skipping to change at page 15, line 10 skipping to change at page 16, line 15
Note that it is not (currently) a requirement to check that a Note that it is not (currently) a requirement to check that a
remote client stores a particular set of data (e.g., the check remote client stores a particular set of data (e.g., the check
that a remote client writes the expected chunk of a file). that a remote client writes the expected chunk of a file).
Enforcing this as a requirement would require a client to know Enforcing this as a requirement would require a client to know
which data is expected (e.g., the full chunk itself or a hash of which data is expected (e.g., the full chunk itself or a hash of
the chunk) which may not be available in all applications. the chunk) which may not be available in all applications.
Checking for a particular hash could be considered as a Checking for a particular hash could be considered as a
requirement in the future that could optionally be employed by requirement in the future that could optionally be employed by
applications. applications.
4.1.6.3. Authorization Checks 4.1.7.3. Authorization Checks
REQUIREMENT(S): In-network storage MUST check the authorization of a REQUIREMENT(S): In-network storage MUST check the authorization of a
client before it executes a supplied request. The in-network client before it executes a supplied request. The in-network
storage MAY use optimizations to avoid such authorization checks storage MAY use optimizations to avoid such authorization checks
as long as the enforced permissions are the the same. as long as the enforced permissions are the the same.
RATIONALE: Authorization granted by a DECADE client are meaningless RATIONALE: Authorization granted by a DECADE client are meaningless
unless unauthorized requests are denied access. Thus, the in- unless unauthorized requests are denied access. Thus, the in-
network storage element must verify the authorization of a network storage element must verify the authorization of a
particular request before it is executed. particular request before it is executed.
4.1.6.4. Credentials Not IP-Based 4.1.7.4. Credentials Not IP-Based
REQUIREMENT(S): Access MUST be able to be granted on other REQUIREMENT(S): Access MUST be able to be granted on other
credentials than the IP address credentials than the IP address
RATIONALE: DECADE clients may be operating on hosts without constant RATIONALE: DECADE clients may be operating on hosts without constant
network connectivity or without a permanent attachment address network connectivity or without a permanent attachment address
(e.g., mobile devices). To support access control with such (e.g., mobile devices). To support access control with such
hosts, DECADE servers must support access control policies that hosts, DECADE servers must support access control policies that
use information other than IP addresses. use information other than IP addresses.
4.1.6.5. Server Involvement 4.1.7.5. Server Involvement
REQUIREMENT(S): A DECADE client MUST be able to indicate, without REQUIREMENT(S): A DECADE client SHOULD be able to indicate, without
contacting the server itself, access control policies for remote contacting the server itself, access control policies for remote
clients' requests. clients' requests.
RATIONALE: See discussion in Section 4.1.5.3. RATIONALE: See discussion in Section 4.1.6.3.
5. Storage Requirements 5. Discovery Requirements
5.1. Requirements 5.1. Requirements
5.1.1. Locating DECADE Servers
5.1.1. Explicit Deletion of Stored Data REQUIREMENT(S): The DECADE Discovery mechanism MUST allow a DECADE
Client to identify one or more DECADE Servers to which it is
authorized to read/write data and to which it may authorize other
DECADE Clients to read/write data, or fail if no such DECADE
Servers are available.
RATIONALE: A basic goal of DECADE is to allow DECADE Clients to
read/write data for access by other DECADE Clients or itself.
Executing the Discovery process should result in a DECADE Client
finding a DECADE Server that it can use for these purposes. It
is possible that no such DECADE Servers are available. Note that
even if a DECADE Client may not successfully locate a DECADE
Server that fits these critieria, it may still read/write data a
DECADE Server if authorized by another DECADE Client.
5.1.2. Support for Clients Behind NATs and Firewalls
REQUIREMENT(S): The Discovery mechanism MUST support DECADE Clients
operating behind NATs and Firewalls without requiring additional
network support (e.g., Application-level Gateways).
RATIONALE: NATs and Firewalls are prevalent in network deployments,
and it is common for Target Applications wishing to include a
DECADE Client to be deployed behind these devices.
5.1.3. Prefer Existing Protocols
REQUIREMENT(S): The DECADE Server discovery mechanism SHOULD prefer
to use existing mechanisms and protocols wherever possible.
RATIONALE: Existing protocols such as DNS and DHCP are widespread.
Using existing protocols, or combinations of the protocols that
have been specified in other contexts, is strictly preferred over
developing a new discovery protocol for DECADE.
6. Storage Requirements
6.1. Requirements
6.1.1. Explicit Deletion of Stored Data
REQUIREMENT(S): DECADE MUST support the ability for a DECADE client REQUIREMENT(S): DECADE MUST support the ability for a DECADE client
to explicitly delete data from its own in-network storage. to explicitly delete data from its own in-network storage.
DECADE MAY have an overwrite flag indicating that an object with DECADE MAY have an overwrite flag indicating that an object with
the same name should be replaced. the same name should be replaced.
RATIONALE: A DECADE client may continually be writing data to its RATIONALE: A DECADE client may continually be writing data to its
in-network storage. Since there may be a limit (e.g., imposed by in-network storage. Since there may be a limit (e.g., imposed by
the storage provider) to how much total storage can be used, some the storage provider) to how much total storage can be used, some
data may need to be removed to make room for additional data. A data may need to be removed to make room for additional data. A
DECADE client should be able to explicitly remove particular DECADE client should be able to explicitly remove particular
data. This may be implemented using existing protocols. data. This may be implemented using existing protocols.
5.1.2. Multiple writing 6.1.2. Multiple writing
REQUIREMENT(S): DECADE MUST NOT allow multiple writers for the same REQUIREMENT(S): DECADE MUST NOT allow multiple writers for the same
object. Implementations raise an error to one of the writers. object. Implementations raise an error to one of the writers.
RATIONALE: This avoids data corruption in a simple way while RATIONALE: This avoids data corruption in a simple way while
remaining efficient. remaining efficient.
5.1.3. Multiple reading 6.1.3. Multiple reading
REQUIREMENT(S): DECADE MUST allow for multiple readers for an REQUIREMENT(S): DECADE MUST allow for multiple readers for an
object. object.
RATIONALE: One characteristic of Target Applications is the ability RATIONALE: One characteristic of Target Applications is the ability
to upload an object to multiple clients. Thus, it is natural for to upload an object to multiple clients. Thus, it is natural for
DECADE to allow multiple readers to read the content DECADE to allow multiple readers to read the content
concurrently. concurrently.
5.1.4. Reading before completely written 6.1.4. Reading before completely written
REQUIREMENT(S): DECADE MAY allow readers to read from objects before REQUIREMENT(S): DECADE MAY allow readers to read from objects before
they have been completely written. they have been completely written.
RATIONALE: Some Target Applications (in particular, P2P streaming) RATIONALE: Some Target Applications (in particular, P2P streaming)
can be sensitive to latency. A technique to reduce latency is to can be sensitive to latency. A technique to reduce latency is to
remove store-and-forward delays for data objects (e.g., make the remove store-and-forward delays for data objects (e.g., make the
object available before it is completely stored). Appropriate object available before it is completely stored). 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.1.5. Hints concerning usage stored data 6.1.5. Hints concerning usage stored data
REQUIREMENT(S): DECADE MAY allow writers of new objects to indicate REQUIREMENT(S): DECADE MAY allow writers of new objects to indicate
specific hints concerning how the objects are expected to be used specific hints concerning how the objects are expected to be used
(e.g., access frequency or time to live). (e.g., access frequency or time to live).
RATIONALE: Different Target Applications may have different usage RATIONALE: Different Target Applications may have different usage
patterns for objects stored at in-network storage. For example, patterns for objects stored at in-network storage. For example,
a P2P live streaming application may indicate to a DECADE server a P2P live streaming application may indicate to a DECADE server
that the objects are expected to have a shore time-to-live, but that the objects are expected to have a shore time-to-live, but
read frequently. The DECADE server may then opt to store the read frequently. The DECADE server may then opt to store the
objects in memory instead of in disk. objects in memory instead of in disk.
5.1.6. Writing model 6.1.6. Writing model
REQUIREMENT(S): DECADE MUST provide at least a writing model (while REQUIREMENT(S): DECADE MUST provide at least a writing model (while
storing an object) that appends data to data already stored. storing an object) that appends data to data already stored.
RATIONALE: Depending on the object size (e.g., chunk size) used by a RATIONALE: Depending on the object size (e.g., chunk size) used by a
Target Application, the application may need to send data to the Target Application, the application may need to send data to the
DECADE server in multiple packets. To keep implementation DECADE server in multiple packets. To keep implementation
simple, the DECADE must at least support the ability to write the simple, the DECADE must at least support the ability to write the
data sequentially in the order received. Implementations MAY data sequentially in the order received. Implementations MAY
allow application to write data in an object out-of-order (but allow application to write data in an object out-of-order (but
MUST NOT overwrite ranges of the object that have already been MUST NOT overwrite ranges of the object that have already been
stored). stored).
5.1.7. Storage Status 6.1.7. Storage Status
REQUIREMENT(S): A DECADE client MUST be able to retrieve current REQUIREMENT(S): A DECADE client MUST be able to retrieve current
resource usage (including list of stored data), resource quotas, resource usage (including list of stored data), resource quotas,
and access permissions for its in-network storage. The returned and access permissions for its in-network storage. The returned
information MUST include resource usage resulting from the information MUST include resource usage resulting from the
client's own usage and usage by other clients that have been client's own usage and usage by other clients that have been
authorized to read/write objects or open connections to that authorized to read/write objects or open connections to that
client's storage. client's storage.
RATIONALE: The resources used by a client are not directly-attached RATIONALE: The resources used by a client are not directly-attached
(e.g., disk, network interface, etc). Thus, the client cannot (e.g., disk, network interface, etc). Thus, the client cannot
locally determine how such resources are being used. Before locally determine how such resources are being used. Before
storing and retrieving data, a client should be able to determine storing and retrieving data, a client should be able to determine
which data is available (e.g., after an application restart). which data is available (e.g., after an application restart).
Additionally, a client should be able to determine resource Additionally, a client should be able to determine resource
availability to better allocate them to remote clients. availability to better allocate them to remote clients.
5.2. Non-Requirements 6.2. Non-Requirements
5.2.1. No ability to update 6.2.1. No ability to update
REQUIREMENT(S): DECADE SHOULD NOT provide ability to update existing REQUIREMENT(S): DECADE SHOULD NOT provide ability to update existing
objects. That is, objects are immutable once they are stored. objects. That is, objects are immutable once they are stored.
RATIONALE: Reasonable consistency models for updating existing RATIONALE: 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 store a servers). If a user needs to update a resource, it can store 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.
6. Implementation Considerations 7. Implementation Considerations
The intent of this section is to collect discussion items and The intent of this section is to collect discussion items and
implementation considerations that have been discovered as this implementation considerations that have been discovered as this
requirements document has been produced. The content of this section requirements document has been produced. The content of this section
will be migrated to an appropriate place as the document and the will be migrated to an appropriate place as the document and the
Working Group progress. Working Group progress.
6.1. Resource Scheduling 7.1. Resource Scheduling
The particular resource scheduling policy may have important The particular resource scheduling policy may have important
ramifications on the performance of applications. This document has ramifications on the performance of applications. This document has
explicitly mentioned simultaneous support for both low-latency explicitly mentioned simultaneous support for both low-latency
applications and latency-tolerant applications. applications and latency-tolerant applications.
Denial of Service attacks may be another risk. For example, Denial of Service attacks may be another risk. For example,
rejecting new requests due to overload conditions may introduce the rejecting new requests due to overload conditions may introduce the
ability to perform a denial of service attack depending on a ability to perform a denial of service attack depending on a
particular DECADE server's scheduling implementation and resource particular DECADE server's scheduling implementation and resource
allocation policies. allocation policies.
6.2. Removal of Duplicate Records 7.2. Removal of Duplicate Records
There are actually two possible scenarios here. The first is the There are actually two possible scenarios here. The first is the
case of removing duplicates within one particular DECADE server (or case of removing duplicates within one particular DECADE server (or
logical server). While not a requirement, as it does not impact the logical server). While not a requirement, as it does not impact the
protocol and is technically not noticeable on message across the protocol and is technically not noticeable on message across the
wire, a DECADE server may implement internal mechanisms to monitor wire, a DECADE server may implement internal mechanisms to monitor
for duplicate records and use internal mechanisms to prevent for duplicate records and use internal mechanisms to prevent
duplication of internal storage. duplication of 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. This is a more difficult problem, and if the of DECADE servers. This is a more difficult problem, and if the
group decides to support this capability, it may require protocol group decides to support this capability, it may require protocol
support. See Section 7.2 for more details. support. See Section 8.2 for more details.
7. Discussion and Open Issues 8. Discussion and Open Issues
7.1. Discussion 8.1. Discussion
Sometimes, several logical in-network storages could be deployed on Sometimes, several logical in-network storages could be deployed on
the same physical network device. In this case, in-network storages the same physical network device. In this case, in-network storages
on the same physical network device can communicate and transfer data on the same physical network device can communicate and transfer data
through internal communication messages. However in-network storages through internal communication messages. However in-network storages
deployed on different physical network devices SHOULD communicate deployed on different physical network devices SHOULD communicate
with in-network storage Access Protocol (IAP). with in-network storage Access Protocol (IAP).
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.2. Open Issues 8.2. Open Issues
Gaming of the Resource Control Mechanism: There has been some Gaming of the Resource Control Mechanism: There has been some
discussion of how applications may be able game the scheduling discussion of how applications may be able game the scheduling
system by manipulating the resource control mechanism, for system by manipulating the resource control mechanism, for
example by specifying many small peers to increase total example by specifying many small peers to increase total
throughput. This is a serious concern, and we need to identify throughput. This is a serious concern, and we need to identify
specific requirements on the protocol (hopefully independent of specific requirements on the protocol (hopefully independent of
particular scheduling/resource control schemes) to help address particular scheduling/resource control schemes) to help address
this. this.
skipping to change at page 19, line 48 skipping to change at page 21, line 48
of what mechanisms (DHCP, HTTP page, etc.) have not been of what mechanisms (DHCP, HTTP page, etc.) have not been
discussed, or even if the protocol should specify one or leave it discussed, or even if the protocol should specify one or leave it
as an implementation detail. This needs to be defined, and as an implementation detail. This needs to be defined, and
specific requirements formulated if needed. specific requirements formulated if needed.
Removal of Duplicate Records Across Servers: If the group wishes to Removal of Duplicate Records Across Servers: If the group wishes to
allow for automated mechanisms to remove duplicates across a allow for automated mechanisms to remove duplicates across a
number of separate servers, some protocol support may need to be number of separate servers, some protocol support may need to be
added. In the case of removing duplicates within a single added. In the case of removing duplicates within a single
(logical) DECADE server, this is simply an implementation (logical) DECADE server, this is simply an implementation
concern. See Section 6 for more details. concern. See Section 7 for more details.
8. Security Considerations 9. Security Considerations
Authorization for access to in-network storage is an important part Authorization for access to in-network storage is an important part
of the requirements listed in this document. Authorization for of the requirements listed in this document. Authorization for
access to storage resources and the data itself is important for access to storage resources and the data itself is important for
users to be able to manage and limit distribution of content. For users to be able to manage and limit distribution of content. For
example, a user may only wish to share particular content with example, a user may only wish to share particular content with
certain peers. certain peers.
If the authorization technique implemented in DECADE passes any If the authorization technique implemented in DECADE passes any
private information (e.g., user passwords) over the wire, it MUST be private information (e.g., user passwords) over the wire, it MUST be
passed in a secure way. passed in a secure way.
9. IANA Considerations 10. IANA Considerations
There are no IANA considerations with this document. There are no IANA considerations with this document.
10. References 11. References
10.1. Normative References 11.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 11.2. Informative References
[I-D.ietf-decade-problem-statement] [I-D.ietf-decade-problem-statement]
Yongchao, S., Zong, N., Yang, Y., and R. Alimi, "DECoupled Yongchao, S., Zong, N., Yang, Y., and R. Alimi, "DECoupled
Application Data Enroute (DECADE) Problem Statement", Application Data Enroute (DECADE) Problem Statement",
draft-ietf-decade-problem-statement-00 (work in progress), draft-ietf-decade-problem-statement-00 (work in progress),
August 2010. August 2010.
[LLSB08] Dave Levin, Katrina LaCurts, Neil Spring, Bobby [LLSB08] Levin, D., LaCurts, K., Spring, N., and B. Bhattacharjee,
Bhattacharjee., "BitTorrent is an Auction: Analyzing and "BitTorrent is an Auction: Analyzing and Improving
Improving BitTorrent's Incentives", In SIGCOMM 2008. BitTorrent's Incentives", SIGCOMM 2008, August 2008.
[PPLive] "PPLive", http://www.pplive.com. [PPLive] "PPLive", <http://www.pplive.com>.
Appendix A. Acknowledgments Appendix A. Acknowledgments
We would also like to thank Haibin Song for substantial contributions We would also like to thank Haibin Song for substantial contributions
to earlier versions of this document. We would also like to thank to earlier versions of this document. We would also like to thank
Reinaldo Penno, Alexey Melnikov, Rich Woundy, Ning Zong, Roni Even, Reinaldo Penno, Alexey Melnikov, Rich Woundy, Ning Zong, Roni Even,
David McDysan, Boerje Ohlman and Dirk Kutscher for contributions David McDysan, Boerje Ohlman and Dirk Kutscher for contributions
(including some text used verbatim) and general feedback. (including some text used verbatim) and general feedback.
Authors' Addresses Authors' Addresses
 End of changes. 52 change blocks. 
102 lines changed or deleted 195 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/