Network Working Group Y. Gu
Internet-Draft H. Song
Intended status: Informational Huawei
Expires: September 9, 2010 Y. Yang
R. Alimi
Yale University
March 8, 2010
DECADE Requirements
draft-gu-decade-reqs-04
Abstract
The target of DECoupled Application Data Enroute (DECADE) is to
provide an open and standard in-network storage system for
applications, primarily P2P applications, to store, retrieve and
manage their data. This draft enumerates and explains requirements,
not only for store and retrieve, but also for data management, access
control and resource control, that should be considered during the
design and implementation of a DECADE 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. the data transport level), but a user of DECADE as a complete
architecture would be guaranteed such functionality.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 9, 2010.
Gu, et al. Expires September 9, 2010 [Page 1]
Internet-Draft DECADE Requirements March 2010
Copyright Notice
Copyright (c) 2010 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 BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology and Concepts . . . . . . . . . . . . . . . . . . . 4
3. General Principles . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Storage Management . . . . . . . . . . . . . . . . . . . . 5
3.2. Low-latency access . . . . . . . . . . . . . . . . . . . . 5
3.3. Efficient Transfer . . . . . . . . . . . . . . . . . . . . 5
3.4. Low equipment and management cost . . . . . . . . . . . . 6
3.5. Application-independent API . . . . . . . . . . . . . . . 6
3.6. Resource Control . . . . . . . . . . . . . . . . . . . . . 6
3.7. Data Object Size . . . . . . . . . . . . . . . . . . . . . 7
4. Data Access . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Reading/Writing Own Storage . . . . . . . . . . . . . . . 7
4.2. Access by Other Users . . . . . . . . . . . . . . . . . . 8
4.3. Communication among In-network Storage Elements . . . . . 9
5. Data Management . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Agnostic of reliability . . . . . . . . . . . . . . . . . 9
5.2. Explicit Deletion of Stored Data . . . . . . . . . . . . . 9
5.3. No ability to update . . . . . . . . . . . . . . . . . . . 10
5.4. Multiple writing . . . . . . . . . . . . . . . . . . . . . 10
5.5. Multiple reading . . . . . . . . . . . . . . . . . . . . . 10
5.6. Reading before completely writen . . . . . . . . . . . . . 10
5.7. Writing model . . . . . . . . . . . . . . . . . . . . . . 11
5.8. Time-to-live for Stored Data . . . . . . . . . . . . . . . 11
5.9. Storage Status . . . . . . . . . . . . . . . . . . . . . . 12
6. Resource Control . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Multiple Applications . . . . . . . . . . . . . . . . . . 12
6.2. Per-Peer, Per-Data Control . . . . . . . . . . . . . . . . 13
6.3. Server Involvement . . . . . . . . . . . . . . . . . . . . 13
7. Authorization . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Per-Peer, Per-Data Read Access . . . . . . . . . . . . . . 14
Gu, et al. Expires September 9, 2010 [Page 2]
Internet-Draft DECADE Requirements March 2010
7.2. Per-User Write Access . . . . . . . . . . . . . . . . . . 14
7.3. Authorization Checks . . . . . . . . . . . . . . . . . . . 14
7.4. Server Involvement . . . . . . . . . . . . . . . . . . . . 15
8. Data Availability . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Offline Usage . . . . . . . . . . . . . . . . . . . . . . 15
9. Error Conditions . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Insufficient Resources . . . . . . . . . . . . . . . . . . 15
9.2. Unavailable and Deleted Data . . . . . . . . . . . . . . . 16
9.3. Overload Conditions . . . . . . . . . . . . . . . . . . . 16
10. Protocol Applicability . . . . . . . . . . . . . . . . . . . . 16
10.1. NATs and Firewalls . . . . . . . . . . . . . . . . . . . . 17
10.2. Connections to Clients . . . . . . . . . . . . . . . . . . 17
11. Security Considerations . . . . . . . . . . . . . . . . . . . 17
12. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 17
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
15.1. Normative References . . . . . . . . . . . . . . . . . . . 18
15.2. Informative References . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Gu, et al. Expires September 9, 2010 [Page 3]
Internet-Draft DECADE Requirements March 2010
1. Introduction
The target of DECoupled Application Data Enroute (DECADE) is to
provide an open and standard in-network storage system for
applications, primarily P2P applications, to store, retrieve and
manage their data. Instead of transferring data directly from
source-owner peer to requesting peer, source-owner peer can store and
manage its content on its in-network storage. The requesting peer
can get the address of the in-network storage pertaining to the
source-owner peer and retrieve data form the storage. This draft
enumerates and explains specific requirements that should be
considered during the design and implementation of a DECADE
system.Though more effort may be made to analyze the suitability to
other applications with the same data operation requirements, we
still consider P2P applications as the only target when we composing
this draft, before any decision has been made.
This document enumerates the requirements to enable target
applications to utilize in-network storage. In this context, using
storage resources includes basic capability such as storing and
retrieving data, and managing data, but also (1) controlling access
by peers with which it is sharing data and (2) controlling the
resources used by remote peers to access that data.
This document also explains the rationale behind requirements that
should be considered in the specification of a protocol for DECADE.
More details about DECADE can be found in the problem statement
[I-D.song-decade-problem-statement].
This document will be updated to track revisions to the problem
statement.
2. Terminology and Concepts
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].
This document uses terms defined in
[I-D.song-decade-problem-statement]. In particular, IAP refers to
the In-network storage Access Protocol, which is the protocol used to
communicate between a DECADE client and DECADE server (in-network
storage) for access control and resource control.
Gu, et al. Expires September 9, 2010 [Page 4]
Internet-Draft DECADE Requirements March 2010
3. General Principles
A number of general principles are identified in this section. These
general principles are important in achieving the goal of DECADE to
be useful in many P2P applications.
3.1. Storage Management
3.1.1. Requirement
DECADE MUST support the ability for a user to own and manage storage
space at in-network storage element.
3.1.2. Rationale
A primary departure from an existing form of in-network storage, P2P
caching, is the ability for applications to manage the data stored.
This allows applications to persist data in the network without fear
that it may be deleted (e.g., pushed out of the cache) by other
users. And it also allows applications to implement policies to meet
their own requirements (e.g., BitTorrent vs. eMule vs. PPLive)
3.2. Low-latency access
3.2.1. Requirements
DECADE MUST provides low-latency access for application clients.
3.2.2. Rationale
Some applications may have requirements on delivery time (e.g., live
streaming). Ueser experience may be unsatifactory if DECADE
introduces much larger latency than applications without in-network
storage between peers.
3.3. Efficient Transfer
3.3.1. Requirements
DECADE MUST allow a user's in-network storage to directly fetch from
other user's in-network storage
3.3.2. Rationale
For example, a requesting peer gets the address of the storage
pertaining to the source-owner peer and then tells its own in-network
storage to fetch the content from the source-owner's in-network
storage. This helps to avoid extra transfers across ISP network
Gu, et al. Expires September 9, 2010 [Page 5]
Internet-Draft DECADE Requirements March 2010
links where possible.
3.4. Low equipment and management cost
3.4.1. Requirements
DECADE SHOULD should have low equipment and management cost per user.
3.4.2. Rationale
Storage should be offered to users at minimal cost (Note that storage
providers may implement higher reliability guarantees if desired).
For example, storages could be "out-of-path" and built with commodity
hardware ("in-path" components must be carrier grade, meaning higher
equipment and management costs). Additionally, P2P applications may
revert to native protocols for data transport.
3.5. Application-independent API
3.5.1. Requirements
DECADE MUST provide simple, application-independent API for P2P
applications to access in-network storage.
3.5.2. Rationale
Since P2P application APIs don't support in-network storage
management, new appliction-independent API must be introduced. The
API should be simple, or it is hard to adopt. Besides, API must
abide by the requirements list above.
3.6. Resource Control
3.6.1. Requirement
DECADE MUST provide the ability for a user to define resource control
policies for managing the resources consumed by requesting users when
reading from / writing to the storage. A DECADE client MUST be able
to control parameters for at least the following types of resources:
o Bandwidth (relative weight)
o Storage space
o Network connections
Gu, et al. Expires September 9, 2010 [Page 6]
Internet-Draft DECADE Requirements March 2010
3.6.2. Rationale
Recent developments in P2P systems have rely on resource-control to
achieve certain application-level goals, such as improving incentives
[LLSB08] and forming distribution topologies [PPLive]. It is
important that DECADE provides basic support for applications to meet
such requirements. Thus, DECADE supports more than the ability read
and write data. In particular, DECADE also supports the ability to
control resources used by remote peers while accessing data in in-
network storage.
There can multiple options when controlling bandwidth used by remote
peers. We indicate that a relative weight can be used to share
bandwidth amongst multiple external peers. Other possibilities (not
exclusive of using a relative weight) may be to also specify a
maximum bandwidth, or indicating an order in which requests should be
served (as is done in eMule). However, care should be taken to not
require complex implementation by the server.
3.7. Data Object Size
3.7.1. Requirement
DECADE MUST allow for efficient data transfer of small objects (e.g.,
16KB) between a DECADE client and in-network storage with only
minimal additional latency required by the protocol.
3.7.2. Rationale
Though P2P 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 chunks that are transferred between
peers. Additionally, the small chunks may have requirements on
delivery time (e.g., in a live-streaming application). DECADE must
enable data to be efficiently transferred amongst peers at this
granularity.
Note that DECADE should allow for efficient data transfer for larger
data objects as well.
4. Data Access
4.1. Reading/Writing Own Storage
Gu, et al. Expires September 9, 2010 [Page 7]
Internet-Draft DECADE Requirements March 2010
4.1.1. Requirement
DECADE MUST support the ability for a DECADE client to read data from
and write data to its own in-network storage.
4.1.2. Rationale
Two basic capabilities for any storage system are reading and writing
data. A DECADE client can read data from and write data to in-
network storage space that it owns.
4.1.3. Requirement
DECADE MUST support the ability for a DECADE client to negotiate with
its In-network storage about which protocol it can use to read data
from and write data to its In-network storage.
4.1.4. Rationale
Since typical data transport protocols (e.g., NFS and WebDAV) already
provide read and write operations for network storage, it is not
necessary for DECADE to define such operations in a new 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.
4.2. Access by Other Users
4.2.1. Requirement
DECADE MUST support the ability for a user to apply access control
policies to users other than itself for its storage. The users with
whom access is being shared can be under a different administrative
domain than the user who owns the in-network storage. The authorized
users may read from or write to the user 's storage.
4.2.2. Rationale
Peers in a P2P application may be located across multiple ISPs under
multiple administrative domains. Thus, to be useful by P2P
applications, DECADE allows a user to specify access control policies
for users that may or may not be known to the user's storage
provider.
Gu, et al. Expires September 9, 2010 [Page 8]
Internet-Draft DECADE Requirements March 2010
4.3. Communication among In-network Storage Elements
4.3.1. Requirement
DECADE SHOULD support the ability for two in-network storage elements
in different administrative domains to store and/or retrieve data
directly between each other. If such a protocol is supported, this
MAY be the same (or a subset or extension of) as the IAP protocol.
4.3.2. Rationale
Allowing server-to-server communication can reduce latency in some
common scenarios. Consider a scenario when a DECADE client is
downloading data into its own storage from another client's in-
network storage. One possibility is for the client to first download
the data itself, and then upload it to its own storage. However,
this causes unnecessary latency and network traffic. Allowing the
data to be downloaded from the remote in-network storage into the
client's own in-network storage can alleviate both.
5. Data Management
5.1. Agnostic of reliability
5.1.1. Requirement
DECADE SHOULD remain agnostic of reliability/fault-tolerance level
offered by storage provider.
5.1.2. Rationale
Providers of a DECADE service may wish to offer varying levels of
service for different applications/users. However, a single
compliant DECADE client should be able to use multiple DECADE
services with differing levels of service.
5.2. Explicit Deletion of Stored Data
5.2.1. Requirement
DECADE MUST support the ability for a DECADE client to explicitly
delete data from its own in-network storage.
5.2.2. Rationale
A DECADE client may continually be writing data to its in-network
storage. Since there may be a limit (e.g., imposed by the storage
Gu, et al. Expires September 9, 2010 [Page 9]
Internet-Draft DECADE Requirements March 2010
provider) to how much total storage can be used, some data may need
to be removed to make room for additional data. A DECADE client
should be able to explicitly remove particular data. This may be
implemented using existing protocols.
5.3. No ability to update
5.3.1. Requirement
DECADE SHOULD NOT provide ability to update existing objects. That
is, objects are immutable once they are stored.
5.3.2. Rationale
Reasonable consistency models for updating existing objects would
significantly complicate implementation (especially if implementation
chooses to replicate data across multiple servers). If a user needs
to update a resource, it can store a new resource and then distribute
the new resource instead of the old one.
5.4. Multiple writing
5.4.1. Requirement
DECADE MUST NOT allow multiple writers for the same object.
Implementations raise an error to one of the writers.
5.4.2. Rationale
This avoids data corruption in a simple way while remaining
efficient.
5.5. Multiple reading
5.5.1. Requirement
DECADE MUST allow for multiple readers for an object.
5.5.2. Rationale
One characteristic of P2P applications is the ablility to upload an
object to multiple peers. Thus, it is natural for DECADE to allow
multiple readers to access the content concurrently.
5.6. Reading before completely writen
Gu, et al. Expires September 9, 2010 [Page 10]
Internet-Draft DECADE Requirements March 2010
5.6.1. Requirement
DECADE MAY allow readers to read from objects before they have been
completely written.
5.6.2. Rationale
Some P2P systems (in particular, 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 stored). Appropriate handling for error
conditions (e.g., a disappearing writer) needs to be specified.
5.7. Writing model
5.7.1. Requirement
DECADE MUST provide at least a writing model (while storing an
object) that appends data to data already stored.
5.7.2. Rationale
Depending on the object size (e.g., chunk size) used by a P2P
application, the application may need to send data to the DECADE
server in multiple packets. To keep implementation simple, the
DECADE must at least support the ability to write the data
sequentially in the order received. Implementations MAY allow
application to write data in an object out-of-order (but MAY NOT
overwrite ranges of the object that have already been stored).
5.8. Time-to-live for Stored Data
5.8.1. Requirement
DECADE MUST support the ability for a DECADE client to indicate a
time-to-live value (or expiration time) indicating a length of time
until particular data is deleted by the in-network storage element.
5.8.2. Rationale
Some data stored by a DECADE client may be usable only within a
certain window of time, such as in live-streaming P2P applications.
Providing a time-to-live value for stored data (e.g., at the time it
is stored) can reduce management overhead by avoiding many 'delete'
commands sent to in-network storage.
Gu, et al. Expires September 9, 2010 [Page 11]
Internet-Draft DECADE Requirements March 2010
5.9. Storage Status
5.9.1. Requirement
A DECADE client MUST be able to retrieve current resource usage
(including list of stored data) and resource quotas on its in-network
storage.
5.9.2. Rationale
The resources used by a client are not directly-attached (e.g., disk,
network interface, etc). Thus, the client cannot locally determine
how such 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). Additionally, a client should
be able to determine resource availability (see Section 3.6) to
better allocate them to remote peers.
6. Resource Control
6.1. Multiple Applications
6.1.1. Requirement
DECADE SHOULD support the ability for users to define resource
sharing policies for multiple applications being run/managed by the
user.
6.1.2. Rationale
A user may own in-network storage and share the in-network storage
resources amongst multiple applications. For example, the user may
run a video-on-demand application and a live-streaming (or even two
different live-streaming applications) application which both make
use of the user's in-network storage. The applications may be
running on different machines and may not directly communicate.
Thus, DECADE should enable the user to determine resource sharing
policies between the applications.
One possibility is for a user to indicate the particular resource
sharing policies between applications out-of-band (not using a
standard protocol), but this requirement may manifest itself in
passing values over IAP to identify individual applications. Such
identifiers can be either user-generated or server-generated and do
not need to be registered by IANA.
Gu, et al. Expires September 9, 2010 [Page 12]
Internet-Draft DECADE Requirements March 2010
6.2. Per-Peer, Per-Data Control
6.2.1. Requirement
A DECADE client MUST be able to assign resource quotas to individual
peers for reading from and writing particular data to its in-network
storage within a particular range of time.
6.2.2. Rationale
P2P applications can rely on control of resources on a per-peer or
per-data basis. For example, application policy may indicate that
certain peers have a higher bandwidth share for receiving data.
Additionally, certain data (e.g., chunks) may be distributed with a
higher priority. As another example, when allowing a remote peer to
write data to a user's in-network storage, the remote peer may be
restricted to write only a certain amount of data. Since the client
may need to manage multiple peers 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 server after which no resources are granted (e.g.,
indicate error as access denied).
6.3. Server Involvement
6.3.1. Requirement
A DECADE client MUST be able to indicate, without contacting the
server itself, resource control policies for peers' requests.
6.3.2. Rationale
One important consideration for in-network storage elements is
scalability, since a single storage element may be used to support
many users. Many P2P applications use small chunk sizes and frequent
data exchanges. If such an application employed resource control and
contacted the in-network storage element for each data exchange, this
could present a scalability challenge for the server as well as
additional latency for clients.
An alternative is to let requesting users get the resource control
policies and userrs can then present the policy to the storage
directly. This can result in reduced messaging handled by the in-
network storage.
Gu, et al. Expires September 9, 2010 [Page 13]
Internet-Draft DECADE Requirements March 2010
7. Authorization
7.1. Per-Peer, Per-Data Read Access
7.1.1. Requirement
A DECADE Client MUST be able to authorize individual peers to read
particular data stored on its in-network storage.
7.1.2. Rationale
A P2P application can control certain application-level policies by
sending particular data (e.g., chunks) to certain peers. It is
important that peers not be able to circumvent such decisions by
arbitrarily reading any currently-stored data in in-network storage.
7.2. Per-User Write Access
7.2.1. Requirement
A DECADE Client MUST be able to authorize individual peers to store
data into its in-network storage.
7.2.2. 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 remote peers
to write data directly to a user's in-network storage. Thus, a
DECADE client should be able to grant only certain peers this
privilege.
Note that it is not (currently) a requirement to check that a peer
stores a particular set of data (e.g., the check that a remote peer
writes the expected chunk of a file). Enforcing this as a
requirement would require a client to know which data is expected
(e.g., the full chunk itself or a hash of the chunk) which may not be
available in all applications. Checking for a particular hash could
be considered as a requirement in the future that could optionally be
employed by applications.
7.3. Authorization Checks
7.3.1. Requirement
In-network storage MAY check the authorization of a client before it
executes a supplied request.
Gu, et al. Expires September 9, 2010 [Page 14]
Internet-Draft DECADE Requirements March 2010
7.3.2. Rationale
Authorization granted by a DECADE client are meaningless unless
unauthorized requests are denied access. Thus, the in-network
storage element must verify the authorization of a particular request
before it is executed.
7.4. Server Involvement
7.4.1. Requirement
A DECADE client MUST be able to indicate, without contacting the
server itself, access control policies for peers' requests.
7.4.2. Rationale
See discussion in Section 6.3.2.
8. Data Availability
8.1. Offline Usage
8.1.1. Requirement
DECADE MAY support the ability for a user to provide authorized
access to its in-network storage even while no DECADE-enabled
applications are currently running or connected to the network.
8.1.2. Rationale
If an application desires, it can authorize peers 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 very often.
9. Error Conditions
9.1. Insufficient Resources
9.1.1. Requirement
DECADE MUST support an error condition indicating to a DECADE client
that resources (e.g., storage space) were not available to service a
request (e.g., storage quota exceeded when attempting to store data).
Gu, et al. Expires September 9, 2010 [Page 15]
Internet-Draft DECADE Requirements March 2010
9.1.2. Rationale
The currently-used resource levels within the in-network storage are
not locally-discoverable, since the resources (disk, network
interfaces, etc) are not directly attached. In order to allocate
resources appropriately amongst peers, a client must be able to
determine when resource limits have been reached. The client can
then respond by explicitly freeing necessary resources or waiting for
such resources to be freed.
9.2. Unavailable and Deleted Data
9.2.1. Requirement
DECADE MUST support error conditions indicating that (1) data was
rejected from being stored, (2) deleted, or (3) marked unavailable by
a storage provider.
9.2.2. Rationale
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). DECADE does not indicate how such
data is identified, but applications using DECADE should not break if
a storage provider is obligated to enforce such policies.
Appropriate error conditions should be indicated to applications.
9.3. Overload Conditions
9.3.1. Requirement
In-network storage, which is operating close to its capacity limit
(e.g., too busy servicing other requests), MUST be able to reject
requests.
9.3.2. Rationale
When in-network storage is operating at a limit where it may not be
able to process additional requests, it should not be required to
generate responses to such additional requests. Forcing the in-
network storage to do so can impair its ability to service existing
requests.
10. Protocol Applicability
Gu, et al. Expires September 9, 2010 [Page 16]
Internet-Draft DECADE Requirements March 2010
10.1. NATs and Firewalls
10.1.1. Requirement
DECADE SHOULD be usable across firewalls and NATs without requiring
additional network support (e.g., Application-level Gateways).
10.1.2. Rationale
Firewalls and NATs are widely used in the Internet today, both in ISP
networks and within households. Deployment of DECADE must not
require modifications to such devices (beyond, perhaps,
reconfiguration).
10.2. Connections to Clients
10.2.1. Requirement
DECADE SHOULD NOT require that network connections be made to DECADE
clients (e.g., from a server to a DECADE client or from a DECADE
client to another DECADE client).
10.2.2. 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).
11. Security Considerations
Authorization for access to in-network storage is an important part
of the requirements listed in this document. Authorization for
access to storage resources and the data itself is important for
users to be able to manage and limit distribution of content. For
example, a user may only wish to share particular content with
certain peers.
If the authorization technique implemented in DECADE passes any
private information (e.g., user passwords) over the wire, it MUST be
passed in a secure way.
12. Discussion
Sometimes, several logical in-network storages could be deployed on
Gu, et al. Expires September 9, 2010 [Page 17]
Internet-Draft DECADE Requirements March 2010
the same physical network device. In this case, in-network storages
on the same physical network device can communicate and transfer data
through internal communication messages. However in-network storages
deployed on different physical network devices SHOULD communicate
with in-network storage Access Protocol (IAP).
To provide fairness among users, the in-network storage provider
should assign resource (e.g., storage, bandwidth, connections) quota
for users. This can prevent a small number of clients from occupying
large amounts of resources on the in-network storage, while others
starve.
13. IANA Considerations
There is no IANA consideration with this document.
14. Acknowledgments
We would like to thank Reinaldo Penno, Alexey Melnikov, Rich Woundy
and Ning Zong for contributions and feedback to this document.
15. References
15.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
15.2. Informative References
[I-D.song-decade-problem-statement]
Yongchao, S., Zong, N., Yang, Y., and R. Alimi, "DECoupled
Application Data Enroute (DECADE) Problem Statement",
draft-song-decade-problem-statement-00 (work in progress),
October 2009.
[LLSB08] Dave Levin, Katrina LaCurts, Neil Spring, Bobby
Bhattacharjee., "BitTorrent is an Auction: Analyzing and
Improving BitTorrent's Incentives", In SIGCOMM 2008.
[PPLive] "PPLive", http://www.pplive.com.
Gu, et al. Expires September 9, 2010 [Page 18]
Internet-Draft DECADE Requirements March 2010
Authors' Addresses
Yingjie Gu
Huawei
Baixia Road No. 91
Nanjing, Jiangsu Province 210001
P.R.China
Phone: +86-25-84565868
Email: guyingjie@huawei.com
Song Haibin
Huawei
Baixia Road No. 91
Nanjing, Jiangsu Province 210001
P.R.China
Phone: +86-25-84565867
Email: melodysong@huawei.com
Yang Richard Yang
Yale University
Email: yry@cs.yale.edu
Richard Alimi
Yale University
Email: richard.alimi@yale.edu
Gu, et al. Expires September 9, 2010 [Page 19]