DECADE Y. Gu
Internet-Draft Huawei
Intended status: Informational D. Bryan
Expires: February 14, 2013 Ethernot.org
Y. Yang
Yale University
P. Zhang
Tsinghua University/Yale
University
R. Alimi
Google
August 13, 2012
DECADE Requirements
draft-ietf-decade-reqs-08
Abstract
The target of the DECoupled Application Data Enroute (DECADE) system
is to provide an open and standard in-network storage system for
applications, primarily P2P (peer-to-peer) applications, to store,
retrieve and manage their data. This draft enumerates and explains
requirements, not only for storage and retrieval, but also for data
management, access control and resource control, that should be
considered during the design and implementation of a DECADE-
compatible system. These are requirements on the entire system; some
of the requirements may eventually be implemented by an existing
protocol with/without some extensions (e.g., a protocol used to read
and write data from the storage system). The requirements in this
document are intended to ensure that a DECADE-compatible system
architecture includes all of the desired functionality for intended
applications.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Gu, et al. Expires February 14, 2013 [Page 1]
Internet-Draft DECADE Requirements August 2012
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 14, 2013.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Gu, et al. Expires February 14, 2013 [Page 2]
Internet-Draft DECADE Requirements August 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. DECADE-compatible Client . . . . . . . . . . . . . . . . . 6
2.2. DECADE-compatible Server . . . . . . . . . . . . . . . . . 6
2.3. DECADE Storage Provider . . . . . . . . . . . . . . . . . 6
2.4. DECADE Account . . . . . . . . . . . . . . . . . . . . . . 6
2.5. Resource Provider . . . . . . . . . . . . . . . . . . . . 6
2.6. Resource Consumer . . . . . . . . . . . . . . . . . . . . 6
2.7. Content Distribution Application . . . . . . . . . . . . . 6
2.8. Target Application . . . . . . . . . . . . . . . . . . . . 7
2.9. Application End-Point . . . . . . . . . . . . . . . . . . 7
2.10. Data Object . . . . . . . . . . . . . . . . . . . . . . . 7
2.11. DECADE-compatible System . . . . . . . . . . . . . . . . . 7
2.12. DECADE Resource Protocol (DRP) Functions . . . . . . . . . 7
2.13. DECADE Standard Data Transfer Protocol (SDT) Functions . . 7
3. System and Protocol Components . . . . . . . . . . . . . . . . 8
4. Requirements Structure . . . . . . . . . . . . . . . . . . . . 9
5. Data Object Requirements . . . . . . . . . . . . . . . . . . . 9
5.1. Data Name Uniqueness . . . . . . . . . . . . . . . . . . . 9
5.2. Verifiable Name-Object Binding . . . . . . . . . . . . . . 10
5.3. Data Object Size . . . . . . . . . . . . . . . . . . . . . 10
5.4. Data Object Attributes . . . . . . . . . . . . . . . . . . 10
5.5. Application-defined Object Properties and Metadata . . . . 11
6. Access and Authorization Requirements . . . . . . . . . . . . 11
6.1. Provider Access . . . . . . . . . . . . . . . . . . . . . 11
6.2. Secure Authorization . . . . . . . . . . . . . . . . . . . 11
6.3. Consumer Access . . . . . . . . . . . . . . . . . . . . . 12
6.4. Provider Authorization When Offline . . . . . . . . . . . 12
6.5. Local Authorization . . . . . . . . . . . . . . . . . . . 12
6.6. Access Control Granularity . . . . . . . . . . . . . . . . 12
6.7. Default Access Permissions . . . . . . . . . . . . . . . . 12
6.8. Connectivity Supporting NAT and Firewall Traversal . . . . 13
6.9. DECADE Server Discovery . . . . . . . . . . . . . . . . . 13
7. Data Transfer Requirements . . . . . . . . . . . . . . . . . . 13
7.1. Negotiable Standard Data Transport Protocol . . . . . . . 13
7.2. Atomic or Partial Read/Write . . . . . . . . . . . . . . . 14
7.3. Secure Data Transport . . . . . . . . . . . . . . . . . . 14
7.4. Concurrent Read . . . . . . . . . . . . . . . . . . . . . 14
7.5. Concurrent Write . . . . . . . . . . . . . . . . . . . . . 14
7.6. Read Before Write Complete . . . . . . . . . . . . . . . . 15
7.7. Redirection of Transport . . . . . . . . . . . . . . . . . 15
8. Resource Control Requirements . . . . . . . . . . . . . . . . 16
8.1. Multiple Applications Sharing Resources . . . . . . . . . 16
8.2. Per-Client Resource Policy . . . . . . . . . . . . . . . . 16
8.3. Distributed Resource Sharing Specification . . . . . . . . 16
8.4. Resource Set . . . . . . . . . . . . . . . . . . . . . . . 17
Gu, et al. Expires February 14, 2013 [Page 3]
Internet-Draft DECADE Requirements August 2012
9. Error and Failure Handling Requirements . . . . . . . . . . . 17
9.1. Illegal Data Object . . . . . . . . . . . . . . . . . . . 17
9.2. Invalid Access Authorization . . . . . . . . . . . . . . . 18
9.3. Insufficient Resources . . . . . . . . . . . . . . . . . . 18
9.4. Overload Condition . . . . . . . . . . . . . . . . . . . . 18
9.5. Attack Mitigation . . . . . . . . . . . . . . . . . . . . 19
10. Management Info Requirements . . . . . . . . . . . . . . . . . 19
10.1. Account Status . . . . . . . . . . . . . . . . . . . . . . 19
11. Security Considerations . . . . . . . . . . . . . . . . . . . 19
11.1. Authentication and Authorization . . . . . . . . . . . . . 20
11.2. Confidentiality . . . . . . . . . . . . . . . . . . . . . 20
11.3. Attack Mitigation . . . . . . . . . . . . . . . . . . . . 20
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
13.1. Normative References . . . . . . . . . . . . . . . . . . . 20
13.2. Informative References . . . . . . . . . . . . . . . . . . 20
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
Gu, et al. Expires February 14, 2013 [Page 4]
Internet-Draft DECADE Requirements August 2012
1. Introduction
The object of the DECoupled Application Data Enroute (DECADE) system
is to provide an open and standard in-network storage for content
distribution applications, where data is typically broken into one or
more chunks and then distributed. This may already include many
types of applications including P2P applications, IPTV (Internet
Protocol Television), and VoD (Video on Demand). (For a precise
definition of the applications targeted in DECADE system, see the
definition for Target Application in Section 2.) Instead of always
transferring data directly from a source/owner client to a requesting
client, the source/owner client can write to and manage its content
on its in-network storage. The requesting client can get the address
of the in-network storage pertaining to the source/owner client and
read data from the storage.
This draft enumerates and explains the rationale behind specific
requirements on the protocol design and on any data store
implementation that may be used to implement DECADE servers that
should be considered during the design and implementation of a
DECADE-compatible system. As such, it does not include general
guiding principles. General design considerations, explanation of
the problem being addressed, and enumeration of the types of
applications to which a DECADE-compatible system may be suited is not
considered in this document. For general information, please see
[RFC6646] and [I-D.ietf-decade-arch].
This document enumerates the requirements to enable target
applications to utilize in-network storage. In this context, using
storage resources includes not only basic capabilities such as
writing, reading, and managing data, but also controlling access for
particular remote clients with which it is sharing data.
Additionally, we also consider controlling the resources used by
remote clients when they access data as an integral part of utilizing
the network storage.
This document discusses requirements pertaining to DECADE-compatible
protocol(s). In certain deployments, several logical in-network
storage systems could be deployed (e.g., within the same
administrative domain). These in-network storage systems can
communicate and transfer data through internal or non-standard
communication messages that are outside of the scope of these
requirements, but they should use DECADE-compatible protocol(s) when
communicating with other DECADE-compatible in-network storage
systems.
Gu, et al. Expires February 14, 2013 [Page 5]
Internet-Draft DECADE Requirements August 2012
2. Terminology
This document uses the term 'In-network storage' which is defined in
[RFC6646].
This document also defines these additional terms:
2.1. DECADE-compatible Client
A DECADE-compatible client uploads and/or retrieves data from DECADE-
compatible servers. We use the shorter term "client" if there is no
ambiguity.
2.2. DECADE-compatible Server
A DECADE-compatible server stores data inside the network, and
thereafter manages both the stored data and access to those data. We
use the shorter term "server" if there is no ambiguity.
2.3. DECADE Storage Provider
A DECADE Storage Provider, or Storage Provider for short, deploys
and/or manages DECADE-compatible server(s) within a network.
2.4. DECADE Account
An account of a DECADE-compatible server has associated cryptographic
credentials for access control, and resource allocation attributes on
the server.
2.5. Resource Provider
A client which has the account cryptographic credentials of a DECADE
account at a DECADE-compatible server. We use the short term
"Provider" if there is no ambiguity.
2.6. Resource Consumer
A client which tries to access a DECADE account but does not have the
account's cryptographic credentials. We use the short term
"Consumer" if there is no ambiguity.
2.7. Content Distribution Application
A Content Distribution Application is an application (e.g., P2P,
traditional CDN, or hybrid P2P/CDN) designed for dissemination of a
large amounts of content (e.g., files, or video streams) to multiple
content consumers. Content Distribution Applications may divide
Gu, et al. Expires February 14, 2013 [Page 6]
Internet-Draft DECADE Requirements August 2012
content into smaller blocks for dissemination.
2.8. Target Application
An application with that includes a DECADE-compatible client along
with other application functionalities to explicitly control the
usage of resources of DECADE-compatible servers to deliver content to
other users. A primary type of Target Application we consider is
Content Distribution Applications. A Target Application divides
content into smaller blocks for more flexible distribution (e.g.,
over multiple application-level paths). We use the term Target
Application to refer to the type of applications that are explicitly
(but not exclusively) supported by DECADE system.
2.9. Application End-Point
An Application End-Point is an instance of a Target Application. A
particular Application End-Point might be a Provider, a Consumer, or
both. For example, an Application End-Point might be an instance of
a video streaming client, or it might be the source providing the
video to a set of clients.
2.10. Data Object
A data object is the unit of data stored and retrieved from a DECADE-
compatible server. The data object is a string of raw bytes. The
server maintains metadata associated with each data object, but the
metadata is not included in the data object.
2.11. DECADE-compatible System
A system which is composed of DECADE-compatible clients, DECADE-
compatible servers and in-network storage. A DECADE-compatible
system MUST obey all the requirements defined in this document.
2.12. DECADE Resource Protocol (DRP) Functions
A set of functions for communication of access control and resource
scheduling policies from a DECADE client to a server, as well as
between servers.
2.13. DECADE Standard Data Transfer Protocol (SDT) Functions
A set of functions to be used to transfer data objects to and from a
DECADE server.
Gu, et al. Expires February 14, 2013 [Page 7]
Internet-Draft DECADE Requirements August 2012
3. System and Protocol Components
To organize requirements, we consider that a DECADE-compatible system
consists of two logical sets of functions, as shown in Figure 1. The
first set of functions, which we refer to as the DECADE Resource
Protocol (DRP) functions, is responsible for communication of access
control and resource scheduling policies from a client to a server,
as well as between servers. A DECADE-compatible system will include
exactly one DRP for interoperability and a common format through
which these policies can be communicated.
Native Application
.-------------. Protocol(s) .-------------.
| Application | <------------------> | Application |
| End-Point | | End-Point |
| | | |
| .--------. | | .--------. |
| | DECADE | | | | DECADE | |
| | Client | | | | Client | |
| `--------' | | `--------' |
`-------------' `-------------'
| ^ | ^
DECADE | | Standard | |
Resource | | Data DRP | | SDT
Protocol | | Transfer | |
(DRP) | | (SDT) | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
v V v V
.=============. DRP .=============.
| DECADE | <------------------> | DECADE |
| Server | <------------------> | Server |
`=============' SDT `============='
Figure 1: Protocol Components and Generic Flow
Second, the second set of functions, referred to as the Standard Data
Transfer (SDT) functions, will be used to transfer data objects to
and from a server. A DECADE-compatible system may support multiple
SDT's. If there are multiple SDT's, a negotiation mechanism will be
used to determine a suitable SDT between the client and server.
The two sets of functions (DRP and SDT) will be either separate or
combined on the wire. If they are combined, DRP messages can be
Gu, et al. Expires February 14, 2013 [Page 8]
Internet-Draft DECADE Requirements August 2012
piggy-backed within some extension fields provided by certain SDT
protocols. In such a scenario, DRP is technically a data structure
(transported by other protocols), but it can still be considered as a
logical protocol that provides the services of configuring DECADE-
compatible resource usage. If the protocols are physically separate
on the wire, DRP can take the form of a separate control connection
open between the a DECADE-compatible client and server. Hence, this
document considers SDT and DRP as two separate, logical functional
components for clarity.
4. Requirements Structure
This document specifies the requirements for the DECADE DRP and SDT
functions, either existing ones or new ones, and storage system to
enable Target Applications to make use of storage within the network,
leaving specific storage system considerations to the implementation
of the storage servers as much as possible. For this reason, we
consider two primary categories of requirements:
o Protocol Requirements: Protocol requirements for Target
Applications to make use of in-network storage within their own
data dissemination schemes. Development of these requirements is
guided by a study of data access, search and management
capabilities used by Target Applications. These requirements may
be met by a combination of existing protocols and new protocols.
o Storage Requirements: Functional requirements necessary for the
back-end storage system employed by the DECADE server.
Development of these requirements is guided by a study of the data
access patterns used by Target Applications. These requirements
should be met by the underlying data transport used by DECADE
system. In this document, we use "data transport" to refer to a
protocol used to read and write data from in-network storage.
This specification discusses the requirements of functionality
implemented with a storage system and within applications, to permit
interoperable communications concerning the manipulation of stored
content.
5. Data Object Requirements
5.1. Data Name Uniqueness
Gu, et al. Expires February 14, 2013 [Page 9]
Internet-Draft DECADE Requirements August 2012
REQUIREMENT(S): Each Data Object should be named to allow access.
DECADE-compatible protocol(s) MUST support a data object naming
scheme that ensures a high probability of uniqueness, with no
coordination among multiple Storage Providers. In other words,
two Data Objects with the same name should be the same content
with high probability. A DECADE-compatible server SHOULD be able
to respond to a DECADE-compatible client with an error indicating
potential name conflicts.
RATIONALE: Although the intention of unique names is to avoid name
collisions, it does not have to be an absolutely zero
possibility. Hence, it is required to provide a collision
handling mechanism.
EXCEPTION: While a DECADE-compatible server is overloaded or
consider a request as an attack, it does not to generate a
response to indicate name collisions.
5.2. Verifiable Name-Object Binding
5.3. Data Object Size
REQUIREMENT(S): DECADE MUST allow for efficient storage and data
transfer of small data objects (e.g., 16KB) without large control
overhead.
RATIONALE: Though Target Applications are frequently used to share
large amounts of data (e.g., continuous streams or large files),
the data itself is typically subdivided into smaller data objects
(chunks) for flexibility (e.g., reliability and multi-path
transmission).
5.4. Data Object Attributes
REQUIREMENT(S): DECADE MUST support the ability to associate a set
of system attributes with a data object with a scope local to a
DECADE-compatible server. In particular, the set MUST include
time-to-live (or expiration time), creation timestamp, object
size, and object type. A DECADE-compatible client, with access
permission, MUST be able to query the set of system attributes.
The transmission of the attributes MUST use an operating system-
independent and architecture-independent standard format. An
ability to extend the set of attributes MUST exist.
RATIONALE: The values of attributes associated with a data object
are local to a particular DECADE-compatible server. These
attributes may be used as hints to the storage system, internal
optimizations, or as additional information query-able by DECADE-
Gu, et al. Expires February 14, 2013 [Page 10]
Internet-Draft DECADE Requirements August 2012
compatible clients. The particular requirement for including
time-to-live (TTL) is that a data object written by a DECADE-
compatible client may be usable only within a certain window of
time, such as in a live-streaming P2P application. Providing a
time-to-live value for a data object (e.g., at the time it is
written) can reduce management overhead by avoiding many 'delete'
commands sent to DECADE-compatible server. The server may still
retain a data object for bandwidth optimization, but this should
be guided by the privacy policy of the DECADE Storage Provider.
5.5. Application-defined Object Properties and Metadata
REQUIREMENT(S): DECADE-compatible clients and DECADE-compatible
servers MUST NOT be able to associate Application-defined
properties (metadata) with data objects beyond what is provided
by Section 5.4.
RATIONALE: Associating key-value pairs that are defined by Target
Applications with data objects introduces substantial complexity.
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 the data object, or (3) storing metadata in a
different data object at the DECADE-compatible server.
6. Access and Authorization Requirements
6.1. Provider Access
REQUIREMENT(S): A Provider MUST be able to access the resources of
its account.
RATIONALE: After a DECADE-compatible client owns an account on a
DECADE-compatible server, it should be able to read data from and
write data to the server.
6.2. Secure Authorization
REQUIREMENT(S): Access to an account on a server MUST be granted to
a provider based on cryptographic security.
RATIONALE: DECADE-compatible clients may be operating on hosts
without constant network connectivity or without a permanent
attachment address (e.g., mobile devices). To support access
control with such hosts, DECADE-compatible servers must support
access control policies that use cryptographic credentials, not
simply by tying access to IP addresses.
Gu, et al. Expires February 14, 2013 [Page 11]
Internet-Draft DECADE Requirements August 2012
6.3. Consumer Access
REQUIREMENT(S): A Provider MUST be able to indicate to its server on
whether a Consumer can access its subscribed resources.
RATIONALE: Endpoints in Target Applications may choose different
servers. Thus, to be useful by Target Applications, a DECADE-
compatible client must be able to specify policies on whether
other DECADE-compatible clients can access its resources. The
other clients may or may not be known to the server.
6.4. Provider Authorization When Offline
REQUIREMENT(S): A Provider MUST be able to grant access to a
Consumer even if the Provider is not actively running or
connected to its DECADE-compatible server.
RATIONALE: If an application desires, it can authorize other clients
to access its storage even after the application exits or network
connectivity is lost. An example use case is mobile scenarios,
where a client can lose and regain network connectivity often.
6.5. Local Authorization
REQUIREMENT(S): A Provider MUST be able to indicate, without
contacting its server, access control policies for Consumers.
DECADE-compatible server MUST be able to authenticate the access
control policies in this situation.
RATIONALE: This requirement is related with the preceding
requirement, but in a perspective (i.e., protocol design). See
discussions in Section 8.3.
6.6. Access Control Granularity
REQUIREMENT(S): A Provider MUST be able to control which individual
clients are authorized to read/write which particular data
objects from/to its in-network storage.
RATIONALE: A Target Application should able to conduct access
control on the granularity of individual clients, individual data
objects.
6.7. Default Access Permissions
Gu, et al. Expires February 14, 2013 [Page 12]
Internet-Draft DECADE Requirements August 2012
REQUIREMENT(S): Unless read or write access is granted by a
Provider, the default permission MUST be no access.
RATIONALE: This requirement is to protect client privacy by default.
6.8. Connectivity Supporting NAT and Firewall Traversal
REQUIREMENT(S): A client that is authorized to access a server MUST
be supported to conduct NAT (Network Address Translation) and
firewall traversal. In particular, network connections between a
DECADE-compatible client and a DECADE-compatible server MUST be
initiated by the client (i.e., the server must not initiate a
connection to the client).
RATIONALE: Firewalls and NATs are widely used in the Internet today,
both in ISP (Internet Service Provider) and Enterprise networks
and by consumers. Many firewalls and NATs are configured by
default to block incoming connections, which helps to mitigate
security risks. Deployment of a DECADE-compatible system must
not require manual modifications to such devices. This
requirement applies to both potential new protocol that may be
developed by the DECADE Working Group and any data transport used
with DECADE protocol.
6.9. DECADE Server Discovery
REQUIREMENT(S): A mechanism for a Provider to discover and connect
to its assigned server MUST be supported. The discovery SHOULD
leverage existing mechanisms and protocols wherever possible. No
new discovery mechanism will be defined unless there is enough
evidence that no existing mechanism can work.
RATIONALE: Existing protocols such as DNS and DHCP are widespread.
Using existing protocols, or combinations of the protocols that
have been specified in other contexts, is strictly preferred over
developing a new discovery protocol.
7. Data Transfer Requirements
7.1. Negotiable Standard Data Transport Protocol
REQUIREMENT(S): A DECADE-compatible client MUST be able to negotiate
with a DECADE-compatible server about which protocol it can use
to read data from and write data. DECADE MUST specify at least
one mandatory transport protocol to be supported by
implementations; usage of a different protocol may be selected
via negotiation.
Gu, et al. Expires February 14, 2013 [Page 13]
Internet-Draft DECADE Requirements August 2012
RATIONALE: Since typical data transport protocols (e.g., NFS and
WebDAV) already provide read and write operations for network
storage, it may not be necessary to define such operations in a
new DECADE protocol. However, because of the particular
application requirements and deployment considerations, different
applications may support different protocols. Thus, a DECADE
client must be able to select an appropriate protocol also
supported by the in-network storage.
7.2. Atomic or Partial Read/Write
REQUIREMENT(S): A DECADE-compatible server MUST support the ability
to read/write a complete data object in one request. It MAY
support range read/write.
RATIONALE: Depending on the object size (e.g., chunk size) used by a
Target Application, the application may need to send data to the
DECADE-compatible server in multiple round.
7.3. Secure Data Transport
REQUIREMENT(S): A secure transport MUST be implemented for all
communications between a DECADE-compatible client and DECADE-
compatible server.
RATIONALE: Target Applications may wish to write sensitive data. To
satisfy this use case, the communication between a DECADE-
compatible client and DECADE-compatible server must be
transported over a secure transport protocol (e.g., SSL/TLS).
7.4. Concurrent Read
REQUIREMENT(S): A DECADE-compatible server MUST allow for multiple
simultaneous readers for a data object.
RATIONALE: One characteristic of Target Applications is the ability
to upload an object to multiple clients. Thus, it is natural for
DECADE-compatible server to allow multiple readers to read the
same object concurrently.
7.5. Concurrent Write
REQUIREMENT(S): A DECADE-compatible server MUST NOT allow multiple
simultaneous writers for the same object. A DECADE-compatible
server SHOULD respond to each of the writers with an error.
Gu, et al. Expires February 14, 2013 [Page 14]
Internet-Draft DECADE Requirements August 2012
RATIONALE: This avoids data corruption in a simple way while
remaining efficient. Alternately, the DECADE-compatible server
would need to either manage locking, handle write collisions, or
merge data, all of which reduce efficiency and increase
complexity.
EXCEPTION: While a DECADE-compatible server is overloaded or
considers a request as an attack, it does not generate a
response.
7.6. Read Before Write Complete
REQUIREMENT(S): A DECADE-compatible server MAY allow readers to read
a data object before it has been completely written. In case of
a write error in such a case, the DECADE-compatible server SHOULD
respond to the reading client with an error indicating that the
write has failed.
RATIONALE: Some Target Applications (in particular, P2P streaming)
can be sensitive to latency. A technique to reduce latency is to
remove store-and-forward delays for data objects (e.g., make the
object available before it is completely written). Appropriate
handling for error conditions (e.g., a disappearing writer) needs
to be specified.
EXCEPTION: While a DECADE-compatible server is overloaded or
considers a request as an attack, it does not generate a
response.
7.7. Redirection of Transport
REQUIREMENT(S): A DECADE-compatible server SHOULD be able to
redirect requests to another DECADE-compatible server. This may
either be in response to an error, failure, overload, or to
support capabilities such as load balancing.
RATIONALE: A DECADE-compatible server may opt to redirect requests
to another server to support capabilities such as load balancing,
or if the implementation decides that another DECADE-compatible
server is in a better position to handle the request due to
either its location in the network, server status, or other
consideration.
EXCEPTION: A DECADE-compatible server can be configured by its
service provider to support or not support redirection
functionality.
Gu, et al. Expires February 14, 2013 [Page 15]
Internet-Draft DECADE Requirements August 2012
8. Resource Control Requirements
8.1. Multiple Applications Sharing Resources
REQUIREMENT(S): A client MUST be able to indicate to a DECADE-
compatible server about resource sharing policies among multiple
Target Applications being run/managed by the same client.
RATIONALE: A client owning a DECADE account may provide the
account's cryptographic credentials to multiple Providers of
multiple target applications. For example, the client may run
one or more video-on-demand application(s) and a live-streaming
application(s) which both make use of the client's in-network
storage. The concurrently running applications may be running on
different machines (e.g., multiple machines at the same home
network) and may not directly communicate, except through user
coordination
8.2. Per-Client Resource Policy
REQUIREMENT(S): A Provider MUST be able to specify resource policies
(bandwidth share, storage quota, and network connection quota) to
individual Consumers for reading from and writing data to its in-
network storage within a particular range of time.
RATIONALE: Target Applications can rely on control of resources on a
per-client basis. For example, application policy may indicate
that certain remote clients have a higher bandwidth share for
receiving data [LLSB08]. Additionally, bandwidth share for
receiving data [LLSB08]. Additionally, certain data (e.g.,
chunks) may be distributed with a higher priority. As another
example, when allowing a remote client to write data to a user's
in-network storage, the remote client may be restricted to write
less than 100MB of data in total. Since the client may need to
manage multiple clients accessing its data, it should be able to
indicate the time over which the granted resources are usable.
For example, an expiration time for the access could be indicated
to the DECADE-compatible server after which no resources are
granted (e.g., indicate error as access denied).
8.3. Distributed Resource Sharing Specification
REQUIREMENT(S): A Provider MUST be able to indicate to its DECADE-
compatible server, without itself contacting the server, resource
control policies for a Consumer. The DECADE-compatible server
MUST be able to authenticate the resource control policies.
Gu, et al. Expires February 14, 2013 [Page 16]
Internet-Draft DECADE Requirements August 2012
RATIONALE: One important consideration for a DECADE-compatible
server is scalability, since a single storage element may be used
to support many users. Many Target Applications use small chunk
sizes and frequent data exchanges. If such an application
employed resource control and contacted the DECADE-compatible
server for each data exchange, this could present a scalability
challenge for the server as well as additional latency for
clients.
The preferred way is to let requesting clients obtain signed
resource control policies (in the form of a token) from the
owning client, and then requesting clients can present the policy
to a DECADE-compatible server directly. This can result in
reduced messaging handled by the DECADE-compatible server.
8.4. Resource Set
REQUIREMENT(S): A DECADE-compatible server MUST allow specification
on the following resources: storage, bandwidth, and number of
connections, and MAY allow additional types of resources to be
specified.
RATIONALE: The minimum set of resources need to include the most
common resources.
9. Error and Failure Handling Requirements
9.1. Illegal Data Object
REQUIREMENT(S): A DECADE-compatible server SHOULD provide an error
indicating that (1) data was rejected from being written, (2)
deleted, or (3) marked unavailable.
RATIONALE: DECADE Storage Providers may require the ability to (1)
avoid storing, (2) delete, or (3) quarantine certain data that
has been identified as illegal (or otherwise prohibited). It is
not specified how such data is identified, but applications
employing DECADE-compatible servers should not break if a Storage
Provider is obligated to enforce such policies. Appropriate
error conditions should be indicated to applications.
EXCEPTION: A DECADE-compatible server should be able to be
configured to suppress Illegal Data Object responses for security
reasons.
Gu, et al. Expires February 14, 2013 [Page 17]
Internet-Draft DECADE Requirements August 2012
9.2. Invalid Access Authorization
REQUIREMENT(S): A DECADE-compatible server SHOULD provide an error
indicating that the request does not have a valid access
authorization.
RATIONALE: DECADE-compatible clients may request data objects to
which they do not have a valid authorization, and DECADE-
compatible servers should be able to signal that this has
occurred. Invalid authorization may be due to a combination of
credential issues as well as additional policies defined by a
Storage Provider.
EXCEPTION: A DECADE-compatible server should be able to be
configured to suppress Invalid Authorization responses for
security reasons.
9.3. Insufficient Resources
REQUIREMENT(S): A DECADE-compatible server SHOULD provide a response
indicating to a DECADE-compatible client that resources (e.g.,
storage space) were not available to service its request (e.g.,
storage quota exceeded when attempting to write data).
RATIONALE: The Insufficient Resources response allows a client to
back off, free up necessary resources or waiting for such
resources to be freed.
EXCEPTION: A DECADE-compatible server may not provide such a
response if doing so increases the load or due to security
concerns.
9.4. Overload Condition
REQUIREMENT(S): A DECADE-compatible server, which is operating close
to its capacity limit (e.g., too busy servicing other requests),
MUST be permitted to reject requests and not be required to
generate response to additional requests. A DECADE-compatible
server MUST also be permitted to redirect requests as a load-
shedding technique.
RATIONALE: The Insufficient Resources response allows a client to
back off, free up necessary resources or waiting for such
resources to be freed.
Gu, et al. Expires February 14, 2013 [Page 18]
Internet-Draft DECADE Requirements August 2012
EXCEPTION: A DECADE-compatible server may not provide such a
response if doing so increases the load or due to security
concerns.
9.5. Attack Mitigation
REQUIREMENT(S): A DECADE-compatible server MUST be permitted to
reject suspicious requests and not be required to generate
responses (e.g., if a client's rate of requests exceeds a pre-
defined threshold).
RATIONALE: Malicious clients may attempt to attack a DECADE-
compatible server by specifying many chunks to increase total
throughput or inciting overload conditions. A DECADE-compatible
server is permitted to reject or ignore requests that are deemed
suspicious according to policies set by its DECADE service
provider.
10. Management Info Requirements
10.1. Account Status
REQUIREMENT(S): A Provider MUST be able to query the resource quota
as well the current usage. The response from the server MUST
include resource usage resulting from both the client's own usage
and usage by other clients that have been authorized to read/
write objects on that client's account.
RATIONALE: The resources used by a client are not necessarily
directly-attached (e.g., disk, network interface, etc). Thus,
the client cannot locally determine how much resources are being
used. Before storing and retrieving data, a client should be
able to determine which data is available (e.g., after an
application restart).
11. Security Considerations
The security model is an important component of a DECADE-compatible
system. It is crucial for users to be able to manage and limit
distribution of content to only authorized parties, and the mechanism
needs to work on the general Internet which spans multiple
administrative and security domains. Previous sections have
enumerated detailed requirements, but this section discusses the
overall approach and other considerations that do not merit
requirements.
Gu, et al. Expires February 14, 2013 [Page 19]
Internet-Draft DECADE Requirements August 2012
11.1. Authentication and Authorization
A DECADE-compatible server must validate an request to access the in-
network storage.
11.2. Confidentiality
DECADE-compatible Servers provide the ability to write raw data
objects (subject to any policies instituted by the owner/
administrator of the Storage Provider). Thus, DECADE-compatible
clients may opt to encrypt data before it is transported to the
server.
11.3. Attack Mitigation
The particular resource control policy may be open to certain attacks
by clients. For example by specifying many small chunks to increase
total throughput or inciting overload conditions are techniques that
may be used by a client.
12. IANA Considerations
There are no IANA considerations with this document.
13. References
13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC6646] Song, H., Zong, N., Yang, Y., and R. Alimi, "DECoupled
Application Data Enroute (DECADE) Problem Statement",
RFC 6646, July 2012.
13.2. Informative References
[I-D.ietf-decade-arch]
Alimi, R., Rahman, A., Kutscher, D., and Y. Yang, "DECADE
Architecture", draft-ietf-decade-arch-08 (work in
progress), July 2012.
[LLSB08] Levin, D., LaCurts, K., Spring, N., and B. Bhattacharjee,
"BitTorrent is an Auction: Analyzing and Improving
BitTorrent's Incentives", SIGCOMM 2008, August 2008.
Gu, et al. Expires February 14, 2013 [Page 20]
Internet-Draft DECADE Requirements August 2012
Appendix A. Acknowledgments
We would also like to thank Haibin Song for substantial contributions
to earlier versions of this document. We would also like to thank
Reinaldo Penno, Alexey Melnikov, Rich Woundy, Ning Zong, Roni Even,
David McDysan, Borje Ohlman, Dirk Kutscher, Akbar Rahman, Xiao Zhu,
Yunfei Zhang, Peng Zhang and Jin Peng for contributions and general
feedback.
Authors' Addresses
Yingjie Gu
Huawei
No. 101 Software Avenue
Nanjing, Jiangsu Province 210012
P.R.China
Phone: +86-25-56624760
Email: guyingjie@huawei.com
David A. Bryan
Ethernot.org
Email: dbryan@ethernot.org
Yang Richard Yang
Yale University
Email: yry@cs.yale.edu
Peng Zhang
Tsinghua University/Yale University
Email: p.zhang@yale.edu
Richard Alimi
Google
Email: ralimi@google.com
Gu, et al. Expires February 14, 2013 [Page 21]
