DECADE                                                             Y. Gu
Internet-Draft                                                    Huawei
Intended status: Informational                                  D. Bryan
Expires: May 3, September 13, 2012                                Polycom, Inc.
                                                                 Y. Yang
                                                         Yale University
                                                                R. Alimi
                                                                  Google
                                                        October 31, 2011
                                                          March 12, 2012

                          DECADE Requirements
                       draft-ietf-decade-reqs-05
                       draft-ietf-decade-reqs-06

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 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 the DECADE 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 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. (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts.
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   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 May 3, September 13, 2012.

Copyright Notice

   Copyright (c) 2011 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.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
   2.  Terminology and Concepts . . . . . . . . . . . . . . . . . . .  6
   3.  Requirements Structure . . . . . . . . . . . . . . . . . . . .  6  7
   4.  Protocol Requirements  . . . . . . . . . . . . . . . . . . . .  7
     4.1.  Overall Protocol Requirements  . . . . . . . . . . . . . .  7
       4.1.1.  Connectivity Concerns  . . . . . . . . . . . . . . . .  7
         4.1.1.1.  NATs and Firewalls . . . . . . . . . . . . . . . .  7  8
         4.1.1.2.  Connections to Clients . . . . . . . . . . . . . .  7  8
       4.1.2.  Security . . . . . . . . . . . . . . . . . . . . . . .  8
         4.1.2.1.  Secure Transport . . . . . . . . . . . . . . . . .  8
         4.1.2.2.  Gaming Prevention  . . . . . . . . . . . . . . . .  8
       4.1.3.  Error and Failure Conditions . . . . . . . . . . . . .  8  9
         4.1.3.1.  Overload Condition . . . . . . . . . . . . . . . .  8  9
         4.1.3.2.  Insufficient Resources . . . . . . . . . . . . . .  8  9
         4.1.3.3.  Unavailable and Deleted Data . . . . . . . . . . .  9 10
         4.1.3.4.  Insufficient Permissions . . . . . . . . . . . . .  9 10
         4.1.3.5.  Redirection  . . . . . . . . . . . . . . . . . . .  9 10
     4.2.  Transfer and Latency Requirements  . . . . . . . . . . . .  9
       4.2.1.  Low-Latency Access . . . . . . . . . . . . . . . . . .  9
       4.2.2. 11
       4.2.1.  Data Object Size . . . . . . . . . . . . . . . . . . . 10
       4.2.3.  Communication among DECADE Servers . . . . . . . . . . 10 11
     4.3.  Data Access Requirements . . . . . . . . . . . . . . . . . 11
       4.3.1.  Reading/Writing Own Storage  . . . . . . . . . . . . . 11
       4.3.2.  Access by Other Users  . Remote Clients . . . . . . . . . . . . . . . 11
       4.3.3.  Negotiable Data Transport Protocol . . . . . . . . . . 11 12
       4.3.4.  Separation of Data and Control Policies  . . . . . . . 12
     4.4.  Data Management Requirements . . . . . . . . . . . . . . . 12
       4.4.1.  Agnostic of reliability  . . . . . . . . . . . . . . . 12
       4.4.2.  Data Object Attributes . . . . . . . . . . . . . . . . 12 13
       4.4.3.  Time-to-live for Written Data Objects  . . . . . . . . 13
       4.4.4.  Application-defined Properties and Metadata  . . . . . 13
       4.4.5.  Offline Usage  . . . . . . . . . . . . . . . . . . . . 13 14
     4.5.  Data Naming Requirements . . . . . . . . . . . . . . . . . 13 14
       4.5.1.  Unique Names . . . . . . . . . . . . . . . . . . . . . 13 14
     4.6.  Resource Control . . . . . . . . . . . . . . . . . . . . . 14 15
       4.6.1.  Multiple Applications  . . . . . . . . . . . . . . . . 14 15
       4.6.2.  Per-Remote-Client, Per-Data Control  . . . . . . . . . 14 15
       4.6.3.  Resource Control Set . . . . . . . . . . . . . . . . . 16
       4.6.4.  Server Involvement . . . . . . . . . . . . . . . . . . 15 16
     4.7.  Authorization  . . . . . . . . . . . . . . . . . . . . . . 15 16
       4.7.1.  Per-Remote-Client, Per-Data Read Access  . . . . . . . 15 16
       4.7.2.  Per-User Write Access  . . . . . . . . . . . . . . . . 15 17
       4.7.3.  Default Access Permissions . . . . . . . . . . . . . . 16 17
       4.7.4.  Authorization Checks . . . . . . . . . . . . . . . . . 16 17
       4.7.5.  Cryptographic Credentials  . . . . . . . . . . . . . . 16 17
       4.7.6.  Server Involvement . . . . . . . . . . . . . . . . . . 16 18
       4.7.7.  Protocol Reuse . . . . . . . . . . . . . . . . . . . . 17
     4.8.  Non-Requirements . . . . . . . . . . . . . . . . . . . . . 17
       4.8.1.  Application-defined Properties and Metadata  . . . . . 17 18
   5.  Storage Requirements . . . . . . . . . . . . . . . . . . . . . 17 18
     5.1.  Immutable Data . . . . . . . . . . . . . . . . . . . . . . 17 18
     5.2.  Explicit Deletion of Data  . . . . . . . . . . . . . . . . 18 19
     5.3.  Multiple writing . . . . . . . . . . . . . . . . . . . . . 18 19
     5.4.  Multiple reading . . . . . . . . . . . . . . . . . . . . . 18 19
     5.5.  Reading before completely written  . . . . . . . . . . . . 18
     5.6.  Hints concerning usage of written data . . . . . . . . . . 19
     5.7.
     5.6.  Writing model  . . . . . . . . . . . . . . . . . . . . . . 19
     5.8. 20
     5.7.  Storage Status . . . . . . . . . . . . . . . . . . . . . . 19 20
   6.  Discovery Requirements . . . . . . . . . . . . . . . . . . . . 20 21
     6.1.  Requirements . . . . . . . . . . . . . . . . . . . . . . . 20 21
       6.1.1.  Locating DECADE Servers  . . .  Support for Clients Behind NATs and Firewalls  . . . . . . . . . . . . 20 21
       6.1.2.  Support for Clients Behind NATs and Firewalls  . . . . 20
       6.1.3.  Prefer Existing Protocols  . . . . . . . . . . . . . . 20 21
   7.  Future  Security Considerations  . . . . . . . . . . . . . . . . . . . . 21
     7.1.  Fairness . . . . . . . . . . . .  Authentication and Authorization . . . . . . . . . . . . . 21
     7.2.  Removal of Duplicate  Encrypted Data Objects  . . . . . . . . . . . . 21
     7.3.  Gaming of the Resource Control Mechanism . . . . . . . . . 21
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 21
     8.1.  Authentication and Authorization . . . . . . . . . . . . . 22
     8.2.  Encrypted Data . . . . . .
     7.3.  Protection against Gaming  . . . . . . . . . . . . . . . . 22
   9.
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 22
   10.
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
     10.1.
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 22
     10.2.
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 22
   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . . 23
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23

1.  Introduction

   The object of the DECoupled Application Data Enroute (DECADE) system
   is to provide an open and standard in-network storage system 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, 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 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 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
   DECADE-compatible system.  As such, it DOES NOT does not include general
   guiding principles.  General design considerations, explanation of
   the problem being addressed, and enumeration of the types of
   applications to which
   DECADE a DECADE-compatible system may be suited is not
   considered in this document.  For general information, please see the problem statement
   [I-D.ietf-decade-problem-statement] and architecture
   [I-D.ietf-decade-arch] drafts. [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 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 should use DECADE DECADE-compatible protocol(s) when
   communicating with other DECADE-capable DECADE-compatible in-network storage
   systems.

2.  Terminology and Concepts

   This document uses terms the term 'In-network storage' which is defined in
   [I-D.ietf-decade-problem-statement].

   This document also defines additional terminology:

   Target Application: An application (typically installed at end-hosts)
   with the ability to explicitly control usage of network and/or
   storage resources to deliver content to a large number of users.
   This includes scenarios where multiple applications or entities
   cooperate, such as with P2P, CDN, and hybrid P2P/CDN architectures.
   Such applications distribute large amounts of content (e.g., a large
   file, or video stream) by dividing the content into smaller blocks
   for more flexible distribution (e.g., over multiple application-level
   paths).  The distributed content is typically immutable (though it may be deleted).
   deleted and replaced).  We use the term Target Application to refer
   to the type of applications that are explicitly (but not exclusively)
   supported by DECADE.

3.  Requirements Structure

   The DECADE protocol is intended to sit between Target Applications
   and a back-end storage system.  DECADE does not intend to develop yet
   another

   DECADE-compatible server: A physical entity that can control and
   manage in-network storage system, but rather to create or a protocol that enables
   Target Applications logical control and management
   component on in-network storage.

   DECADE-compatible client: An interface for target applications to
   make use of in-network storage within the network,
   leaving specific storage system considerations to the implementation
   of the in DECADE servers as much system.  DECADE client is
   usually a software hosted on a end device, such as possible.  For this reason, we have
   divided the requirements into two primary categories:

   o  Protocol Requirements: Protocol requirements for Target
      Applications a PC or laptop.  A
   DECADE-compatible client be employed by a target applications to
   communicate with DECADE server to make use of in-network storage within their own
      data dissemination schemes.  Development storage.

   DECADE-compatible protocol: A protocol between a DECADE-compatible
   client and a DECADE-compatible server.  In this document, a DECADE-
   compatible protocol represents the protocols, both existing and
   potential new protocols, that can be used by a DECADE-compatible
   client and DECADE-compatible server to communicate with each other.

   DECADE service provider: the provider who provides DECADE service to
   a DECADE-compatible client.  DECADE service provider can be an in-
   network storage provider, or service provider who serve users of
   DECADE-compatible clients by renting or purchasing in-network storage
   from in-network storage provider.

   DECADE-compatible system: a system which is composed of DECADE-
   compatible clients, DECADE-compatible servers and in-network storage.
   A DECADE-compatible protocol is used for communication between
   DECADE-compatible clients and DECADE-compatible servers.  A DECADE-
   compatible system MUST obey all the requirements defined in this
   document.

3.  Requirements Structure

   A DECADE-compatible protocol is intended to sit between Target
   Applications and a storage system.  This document does not intend to
   develop yet another storage system or a new protocol, but rather to
   explore the requirements for the DECADE protocols, either existing
   ones or a potential new one, 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 have
   divided the requirements into two primary categories:

   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. DECADE
      system.  In this document, we use "data transport" to refer to a
      protocol used to read and write data from DECADE in-network storage.

   Note that a third category also enumerates

   This specification discusses the requirements on of functionality
   implemented with a storage system and within applications, to permit
   interoperable communications concerning the
   protocol manipulation of stored
   content.

4.  Protocol Requirements

   This section details the requirements of DECADE-compatible
   protocol(s) that can be used to discover in a DECADE-compatible system
   implementation.  The DECADE Servers.

   It should also protocols can be made clear that the approach is to make DECADE a
   simple protocol, while still enabling its usage within many Target
   Applications.  For this reason, and to further reinforce the
   distinction between DECADE and a storage system, in some cases we
   also highlight the non-requirements of existing protocols, as
   long as they satisfy the protocol.  These non- requirements are intended to capture behaviors that will NOT be
   assumed to be needed by DECADE's Target Applications and hence not
   present specified in the DECADE protocol.

   Finally, some implementation considerations are provided, which while
   not strictly requirements, are intended to provide guidance and
   highlight potential points that need to be considered by the this document, or
   a new protocol
   developers, and later by implementors.

4.  Protocol Requirements

   This section details which must obey all the requirements of DECADE protocol(s). too.

4.1.  Overall Protocol Requirements

4.1.1.  Connectivity Concerns
4.1.1.1.  NATs and Firewalls

   REQUIREMENT(S):  DECADE client to server protocols SHOULD  DECADE-compatible protocol(s) MUST be usable across
       firewalls and NAT (Network Address Translation) devices
       without requiring additional network support (e.g., Application-
       level Gateways). devices.  DECADE
       protocol MUST NOT pass literal IP addresses in messages.

   RATIONALE:  Firewalls and NATs are widely used in the Internet today,
       both in ISP (Internet Service Provider) and Enterprise networks
       and by consumers.  Deployment of DECADE a DECADE-compatible system must
       not require modifications to such devices (beyond, perhaps,
       reconfiguration).
       Note that this  This requirement applies to both any potential new
       protocol that may be developed by the DECADE Working Group and
       any data transport used with DECADE. DECADE protocol.

4.1.1.2.  Connections to Clients

   REQUIREMENT(S):  DECADE SHOULD require that network  Network connections between DECADE-compatible client
       and DECADE-compatible server MUST be
       made from DECADE clients to DECADE servers initiated by the client
       (i.e., not from the server to must not initiate a connection with the DECADE
       client).

   RATIONALE:  Many household networks and operating systems have
       firewalls and NATs configured by default to block incoming
       connections.  To ease deployment by avoiding configuration
       changes and help mitigate security risks, DECADE should a DECADE-compatible
       client must not
       require clients be required to listen for any incoming network
       connections (beyond what is required by any other already-deployed already-
       deployed application).

4.1.2.  Security

4.1.2.1.  Secure Transport

   REQUIREMENT(S):  DECADE  A secure transport MUST contain a mode in which be implemented for all
       communication
       communications between a DECADE DECADE-compatible client and server is over a secure
       transport that provides confidentiality, integrity, and
       authentication. DECADE-
       compatible server.

   RATIONALE:  Target Applications may wish to write sensitive data.  To
       satisfy this use case, DECADE must provide a mode in which all the communication between a DECADE DECADE-
       compatible client and DECADE-compatible server occurs must be
       transported over a secure transport protocol (e.g., SSL/TLS).

4.1.3.  Error and Failure Conditions

4.1.3.1.  Overload Condition

4.1.2.2.  Gaming Prevention
   REQUIREMENT(S):  In-network storage, which is operating close to its
       capacity limit (e.g., too busy servicing other requests),  A DECADE-compatible server MUST be permitted to
       reject suspicious requests and not be required to generate
       responses to additional requests.  In-network storage MUST also
       be permitted to (e.g., if a client's rate of requests exceeds a pre-
       defined threshold).

   RATIONALE:  Malicious clients may attempt to attack a DECADE-
       compatible server by specifying many chunks to increase total
       throughput or inciting overload conditions.  A DECADE-compatible
       server is permitted to reject or ignore requests that are deemed
       suspicious according to policies set by its DECADE service
       provider.

4.1.3.  Error and Failure Conditions

4.1.3.1.  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 (see Section
       4.1.3.5) as a
       load-shedding load- shedding technique.

   RATIONALE:  Forcing the in-network storage a DECADE-compatible server to respond to requests
       when operating close to its capacity can impair its ability to
       service existing requests, and thus is permitted to avoid
       generating responses response to additional requests.

4.1.3.2.  Insufficient Resources

   REQUIREMENT(S):  DECADE MUST support  A DECADE-compatible server SHOULD be able to provide
       an error condition indicating to a DECADE DECADE-compatible client that
       resources (e.g., storage space) were not available to service a
       request (e.g., storage quota exceeded when attempting to write
       data).

   RATIONALE:  The currently-used resource levels within the in-network
       storage are not locally-discoverable, since the resources (disk,
       network interfaces, etc) are may not directly attached. be locally-discoverable.  In order to allocate
       resources appropriately amongst remote clients, a DECADE-
       compatible client must be able to determine when resource limits
       have been reached.  The DECADE-compatible client can then respond
       by explicitly freeing necessary resources or waiting for such
       resources to be freed.

   EXCEPTION:  While a DECADE-compatible server is in the situation that
       is described in Section 4.1.2.2 or Section 4.1.3.1, it need not
       to respond with error condition.

4.1.3.3.  Unavailable and Deleted Data

   REQUIREMENT(S):  DECADE MUST support  A DECADE-compatible server SHOULD be able to provide
       error conditions indicating that (1) data was rejected from being
       written, (2) deleted, or (3) marked unavailable by a storage
       provider.

   RATIONALE:  Storage  DECADE service 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  It is
       not
       indicate specified how such data is identified, but applications using
       DECADE
       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 configured
       as not respond to any request to access unavailable or deleted
       data on the in- network storage, for example, for security
       reasons.

4.1.3.4.  Insufficient Permissions

   REQUIREMENT(S):  DECADE  A DECADE-compatible server MUST support be able to provide
       error conditions indicating that the requesting client does not
       have sufficient permissions to access requested data objects.

   RATIONALE:  DECADE  DECADE-compatible clients may request objects to which
       they do not have sufficent sufficient access permissions, and DECADE DECADE-
       compatible servers must be able to signal that this has occurred.  Note that access
       Access permissions may be insufficient due to a combination of
       the credentials presented by a client as well as additional
       policies defined by the storage provider.

4.1.3.5.  Redirection

   REQUIREMENT(S):  DECADE SHOULD support the ability for a DECADE  A DECADE-compatible server SHOULD be able to
       redirect requests to another DECADE DECADE-compatible server.  This may
       either be in response to an error, failure, or overload
       condition, or to support capabilities such as load balancing.

   RATIONALE:  A DECADE 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 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.

4.2.  Transfer and Latency Requirements

4.2.1.  Low-Latency Access  Data Object Size

   REQUIREMENT(S):  DECADE SHOULD provide "low-latency" access for
       application clients.  DECADE MUST allow clients to specify at
       least two classes of services: lowest possible latency and
       latency non-critical.

   RATIONALE:  Some applications may have requirements on delivery time
       (e.g., live streaming [PPLive]).  The user experience may be
       unsatisfactory if the use of in-network storage results in lower
       performance than connecting directly to remote clients over a
       low-speed, possibly congested uplink.  Additionally, the overhead
       required for control-plane operations in DECADE must not cause
       the latency to be higher than for a low-speed, possibly congested
       uplink.  While it is impossible to make a guarantee that a system
       using in-network storage will always outperform a system that
       does not for every transfer, the overall performance of the
       system should be improved compared with direct low-speed uplink
       connections, even considering control overhead.

4.2.2.  Data Object Size

   REQUIREMENT(S):  DECADE  DECADE-compatible protocol(s) MUST allow for
       efficient data transfer of small objects (e.g., 16KB) between a DECADE
       DECADE-compatible client and in-network storage with minimal
       additional latency imposed by the protocol. protocol(s).

   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 chunks that
       are transferred between clients.  Additionally, the small chunks clients may have requirements on be
       sensitive to the delivery time of chunks (e.g., in a live-streaming live-
       streaming application).  DECADE  DECADE-compatible protocol(s) must
       enable data to be efficiently transferred amongst DECADE-
       compatible clients at this granularity.  It is important
       to note that DECADE may be used to store and retrieve larger
       objects, but protocol(s) should not be designed such that usage
       with smaller data objects cannot meet the requirements of Target
       Applications.

4.2.3.  Communication among DECADE Servers

4.3.  Data Access Requirements

4.3.1.  Reading/Writing Own Storage

   REQUIREMENT(S):  DECADE SHOULD support the ability for two in-network
       storage elements in different administrative domains to write
       and/or read data directly between each other (if authorized as
       described in Section 4.7).  If such a capability is supported,
       this MAY be the same (or a subset or extension of) as the DECADE  DECADE-compatible protocol(s) used by clients to access data.

   RATIONALE:  Allowing server-to-server communication can reduce
       latency in some common scenarios.  Consider a scenario when MUST enable a
       DECADE client is downloading data into its own storage from
       another client's in-network storage.  One possibility is for the DECADE-
       compatible client to first download the read data itself, from and then upload it write data to its own in-
       network storage.  However, this uploading causes unnecessary
       latency and network traffic.  Allowing the data to be downloaded
       from the remote in-network storage into the client's own in-
       network storage can alleviate both.

4.3.  Data Access Requirements

4.3.1.  Reading/Writing Own Storage

   REQUIREMENT(S):  DECADE MUST support the ability for a DECADE client
       to read data from and write data to its own in-network storage.

   RATIONALE:  Two basic capabilities for any storage system are reading

   RATIONALE:  Two basic capabilities for any storage system are reading
       and writing data.  A DECADE DECADE-compatible client can read data from
       and write data to in-network storage space that it owns.

4.3.2.  Access by Other Users Remote Clients

   REQUIREMENT(S):  DECADE  A DECADE-compatible client MUST support the ability for a user be able to apply
       access control policies to users remote DECADE-compatible clients other
       than itself for its storage.  The users remote DECADE-compatible
       clients with whom access is being shared can be under a different
       administrative domain than the user DECADE-compatible client who owns
       the in-
       network storage.  The authorized users may read from or write to
       the user's in-network storage.

   RATIONALE:  Endpoints in Target Applications may be located across
       multiple ISPs under multiple administrative domains.  Thus, to be
       useful by Target Applications, DECADE allows a user DECADE-compatible client must be
       able to implement specify access control policies for users remote DECADE-
       compatible clients that may or may not be known to the user's storage client's
       own DECADE service provider.

4.3.3.  Negotiable Data Transport Protocol

   REQUIREMENT(S):  DECADE MUST support the ability for a DECADE  DECADE-compatible client MUST be able to negotiate
       with its in-network storage DECADE server about which protocol it can use to read data
       from and write data to its In-network in-network storage.  DECADE system
       MUST specify at least one mandatory protocol to be supported by
       implementations; usage of a different protocol may be selected
       via negotiation.

   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 for DECADE 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.  This requirement also
       follows as a result of the requirement of Separation of Control
       and Data Operations (Section 4.3.4).

4.3.4.  Separation of Data and Control Policies

   REQUIREMENT(S):  DECADE Protocol(s)  DECADE-compatible protocol(s) MUST only provide a minimal
       set of core operations to support diverse policies implemented
       and desired by Target Applications. Applications, and MAY provide additional
       operations.

   RATIONALE:  Target Applications support many complex behaviors and
       diverse policies to control and distribute data, such as (e.g.,
       search, index, setting permissions/passing authorization tokens).
       Thus, to support such Target Applications, these behaviors must
       be logically separated from the data transfer operations (e.g.,
       read, write).  Some minimal overlap (for example obtaining
       credentials needed to encrypt or authorize data transfer using
       control operations) may be is required to be directly specified supported by
       DECADE. DECADE-
       compatible protocol(s).

4.4.  Data Management Requirements

4.4.1.  Agnostic of reliability

   REQUIREMENT(S):  DECADE SHOULD  DECADE-compatible protocol(s) MUST remain agnostic
       of reliability/ fault-tolerance level offered by storage DECADE service
       provider.

   RATIONALE:  Providers of a DECADE service may wish to offer varying
       levels of service for different applications/users.  However, a
       single compliant DECADE DECADE-compatible client should must be able to use multiple
       DECADE services with differing levels of service.

4.4.2.  Data Object Attributes

   REQUIREMENT(S):  DECADE  DECADE-compatible protocol(s) MUST support the
       ability to associate attributes with data objects with a scope
       local to a DECADE DECADE-compatible server, and for DECADE DECADE-compatible
       clients to query these attributes.  DECADE  DECADE-compatible protocol(s)
       MUST transmit any attributes using an operating
       system-independent system-
       independent and architecture-independent standard format.  If
       there is a need to design any DECADE protocol(s) protocols, they MUST be
       designed such that new attributes can be added by later protocol
       revisions or extensions.

   RATIONALE:  DECADE supports associating  A DECADE-compatible client can associate attributes
       (e.g., a time-to- live, creation timestamp, or object size) with
       a data object.  These attributes are local to a data object
       stored by a particular DECADE DECADE-compatible server, and are thus not
       applied to any DECADE DECADE-compatible server or client to which the
       data object is copied.  These attributes may be used as hints to
       the storage system, internal optimizations, or as additional
       information queryable query-able by DECADE DECADE-compatible clients.

4.4.3.  Time-to-live for Written Data Objects

   REQUIREMENT(S):  DECADE MUST support the ability for a DECADE  A DECADE-compatible client MUST be able to indicate
       a time-to-live time-to- live value (or expiration time) indicating a length of
       time until particular data can be deleted by the in-
       network storage element. a DECADE-compatible
       server.

   RATIONALE:  Some data objects written by a DECADE DECADE-compatible 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 data objects (e.g., at the time they are written) can reduce
       management overhead by avoiding many 'delete' commands sent to
       in-network storage.
       DECADE-compatible server.  The in-network storage may still keep
       the data in cache for bandwidth optimization.  But this is guided
       by the privacy policy of the DECADE service provider.

4.4.4.  Offline Usage  Application-defined Properties and Metadata
   REQUIREMENT(S):  DECADE MAY support the ability for a user to provide
       authorized access to its in-network storage even if the user has
       no DECADE applications actively running or connected to the
       network.

   RATIONALE:  If an application desires, it can authorize remote  DECADE-compatible clients to access its and DECADE-compatible
       servers MUST NOT be able to associate Application-defined
       properties (metadata) with data objects beyond what is provided
       by Section 4.4.2.

   RATIONALE:  Associating key-value pairs that are defined by Target
       Applications with data objects introduces substantial complexity
       to the protocol(s).  If Target Applications wish to associate
       additional metadata with a data object, possible alternatives
       include (1) managing such metadata within the Target Application
       itself, (2) storing metadata inside of the data object, or (3)
       storing metadata in a different data object at the DECADE-
       compatible server.

4.4.5.  Offline Usage

   REQUIREMENT(S):  A DECADE-compatible client MAY provide authorized
       access from remote clients to its in-network storage even if the
       DECADE client is actively running or connected to a DECADE-
       compatible server.

   RATIONALE:  If an application desires, it can authorize remote
       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 very often.

4.5.  Data Naming Requirements

4.5.1.  Unique Names

   REQUIREMENT(S):  DECADE  DECADE-compatible protocol(s) MUST support a data
       object naming scheme that ensures a high probability of
       uniqueness and supports the operation of
       DECADE DECADE-compatible
       servers under diverse administrative domains with no
       coordination.  DECADE  DECADE-compatible server SHOULD provide a mechanism (minimally
       rejection) be able to handle respond
       to DECADE-compatible client with error condition indicating the improbable case
       name of a collision. the object conflicts with other object.

   RATIONALE:  When writing a data object, a DECADE DECADE-compatible Client
       should be able to write 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  Although the intention is
       to satisfy this requirement probabilistically (e.g., using
       a hashing mechanism). avoid name collision, it's not absolutely zero possibility.
       As a result, it is wise required to provide a collision handling mechanism, even if the probability of
       collisions
       mechanism.

   EXCEPTION:  While a DECADE-compatible server is extremely low. in situations
       described in Section 4.1.2.2 or Section 4.1.3.1, it need not to
       generate a response to the client.

4.6.  Resource Control

4.6.1.  Multiple Applications

   REQUIREMENT(S):  DECADE SHOULD support the ability for users  A DECADE-compatible client MUST be able to
       define indicate
       to a DECADE-compatible server about resource sharing policies for
       multiple target applications
       (DECADE clients) being run/managed by the same user.

   RATIONALE:  A user may own in-network storage and share the in-
       network storage resources amongst multiple target applications.
       For example, the user may run one or more video-on-demand
       application(s) and a live-streaming application(s) 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 should be able 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 within DECADE DECADE-compatible protocol(s) to identify
       individual applications.  Such identifiers can be either user-generated user-
       generated or server-generated and do not need to be registered by
       IANA.

4.6.2.  Per-Remote-Client, Per-Data Control

   REQUIREMENT(S):  A DECADE DECADE-compatible client MUST be able to assign
       resource policies (bandwidth share, storage quota, and network
       connection quota) to individual remote clients for reading from
       and writing particular data to its in-network storage within a
       particular range of time.  The DECADE server MUST enforce these constraints.

   RATIONALE:  Target Applications can rely on control of resources on a
       per-remote-client or per-data 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 only a certain amount less than 100MB of data. 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).

4.6.3.  Server Involvement  Resource Control Set

   REQUIREMENT(S):  A DECADE client SHOULD  DECADE-compatible protocol(s) MUST define a minimum
       set of resource control methods, and MAY add additional set of
       resource control methods.

   RATIONALE:  The minimum set of resource control methods need to
       include the most common resource control methods.  Implementors
       can add proprietary set of resource control methods in their own
       implementation.

4.6.4.  Server Involvement

   REQUIREMENT(S):  A DECADE-compatible client MUST be able to indicate
       to a
       DECADE DECADE-compatible server, without itself contacting the
       server, resource control policies for remote clients' requests.
       A DECADE-compatible server MUST be able to authenticate the
       resource control policies in this situation.

   RATIONALE:  One important consideration for in-network storage
       elements 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 in-network storage
       element DECADE-compatible
       server for each data exchange, this could present a scalability
       challenge for the server as well as additional latency for
       clients.

       Our

       The preferred alternative way is to let requesting users clients obtain signed
       resource control policies (in the form of a token) from the
       owning user, client, and then users requesting clients can then present the policy
       to
       the storage a DECADE-compatible server directly.  This can result in
       reduced messaging handled by the in-network storage. DECADE-compatible server.

4.7.  Authorization

4.7.1.  Per-Remote-Client, Per-Data Read Access

   REQUIREMENT(S):  A DECADE DECADE-compatible Client MUST be able to control
       which individual remote clients are authorized to read particular
       data from its in-network storage.

   RATIONALE:  A Target Application can control certain application-
       level policies by sending particular data (e.g., chunks) to
       certain remote clients.  It is important that remote clients not
       be able to circumvent such decisions by arbitrarily reading any
       data in in-network storage.

4.7.2.  Per-User Write Access

   REQUIREMENT(S):  A DECADE DECADE-compatible Client MUST be able to control
       which individual remote clients are authorized to write data into
       its in-network storage.

   RATIONALE:  The space managed by a user in in-network storage can be
       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
       storage.  Thus, a DECADE DECADE-compatible client should be able to
       grant only certain remote clients this privilege.

4.7.3.  Default Access Permissions

   REQUIREMENT(S):  Unless read or write access is granted by a DECADE
       Client to a remote client, the default access MUST be no access.

   RATIONALE:  The current leading proposal for an access control model
       in DECADE working group is via token passing, resulting in a
       system with little state on the server side.

4.7.4.  Authorization Checks

   REQUIREMENT(S):  In-network storage  A DECADE-compatible server MUST check the
       authorization of a client before it executes a supplied request.

   RATIONALE:  The in-network
       storage MAY use optimizations data stored at a DECADE-compatible server is assumed
       to be private, and thus not accessible to avoid such authorization checks
       as long as the enforced permissions are the same.

   RATIONALE:  Authorization granted by a DECADE DECADE-enabled 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. explicitly granted permission.

4.7.5.  Cryptographic Credentials

   REQUIREMENT(S):  Access MUST be able to be granted using
       cryptographic credentials.

   RATIONALE:  DECADE  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 DECADE-compatible servers must support
       access control policies that use cryptographic credentials, not
       simply by tying access to IP addresses.

4.7.6.  Server Involvement

   REQUIREMENT(S):  A DECADE DECADE-compatible client SHOULD MUST be able to indicate,
       without contacting the server itself, access control policies for
       remote clients' requests.  DECADE-compatible server MUST be able
       to authenticate the access control policies in this situation.

   RATIONALE:  See discussion in Section 4.6.3. 4.6.4.

4.7.7.  Protocol Reuse

   REQUIREMENT(S):  If possible,  DECADE SHOULD reuse existing protocol and mechanisms
       for Authentication, Access, and Authorization (AAA).  No new AAA
       protocol and mechanism are going to be defined unless there is
       explicit proof that existing protocol and mechanisms are not
       applicable.

   RATIONALE:  If possible, reusing an existing AAA protocol/mechanism
       will minimize the development required by applications, and will
       maximize interoperability of the DECADE protocol DECADE-compatible protocol(s)
       with existing infrastructure.

4.8.  Non-Requirements

4.8.1.  Application-defined Properties and Metadata

5.  Storage Requirements

   This section details the requirements of the underlying storage used
   to support DECADE-compatible protocol(s).

5.1.  Immutable Data

   REQUIREMENT(S):  DECADE MUST NOT provide a mechanism for associating
       Application-defined properties (metadata) with  The data objects
       beyond what is provided by Section 4.4.2.

   RATIONALE:  Associating key-value pairs that are defined by Target
       Applications with data objects introduces substantial complexity
       to the DECADE protocol.  If Target Applications wish to associate
       additional metadata with a data object, possible alternatives
       include (1) managing such metadata within the Target Application
       itself, (2) storing metadata inside of the data object, or (3)
       storing metadata in a different data object at the DECADE server.

5.  Storage Requirements

   This section details the requirements of the underlying storage used
   to support the DECADE protocol(s).

5.1.  Immutable Data

   REQUIREMENT(S):  DECADE MUST only store and manage data objects that
       are immutable once they MUST be immutable once they are
       written to storage.

   RATIONALE:  Immutable data objects are an important simplification in
       DECADE.
       DECADE-compatible system.  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 the content owners have to update a resource, it can write a
       new resource and then distribute
       modify the written data objects, there are many ways to do so.
       First, they can use different data names for different object
       versions.  Secondly, they can split single monolithic files into
       fragments, so that new resource instead of the
       old one. fragment versions could be substituted
       later (e.g. corrections or updated advertising) via a play list.

5.2.  Explicit Deletion of Data

   REQUIREMENT(S):  DECADE MUST support the ability for a DECADE  A DECADE-compatible client MUST be able to
       explicitly delete data from its own in-network storage.

   RATIONALE:  A DECADE DECADE-compatible client may continually be writing
       data to its 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 data may need to be removed to make room for
       additional data.  A
       DECADE DECADE-compatible client should be able to
       explicitly remove particular data.  This may be implemented using
       existing protocols.

5.3.  Multiple writing

   REQUIREMENT(S):  DECADE  A DECADE-compatible server MUST NOT allow multiple
       simultaneous writers for the same object.  Implementations MUST raise an error  A DECADE-compatible
       server SHOULD respond to one each of the writers. writers with error condition
       indicating the attempt of simultaneous writing.

   RATIONALE:  This avoids data corruption in a simple way while
       remaining efficient.  Alternately, the DECADE 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 in the situation that
       is described in Section 4.1.2.2 or Section 4.1.3.1, it need not
       generate a response.

5.4.  Multiple reading

   REQUIREMENT(S):  DECADE  A DECADE-compatible server MUST allow for multiple
       simultaneous readers for an object.

   RATIONALE:  One characteristic of Target Applications is the ability
       to upload an object to multiple clients.  Thus, it is natural for
       DECADE
       DECADE-compatible server to allow multiple readers to read the
       content concurrently.

5.5.  Reading before completely written

   REQUIREMENT(S):  DECADE  A DECADE-compatible server MAY allow readers to read
       from objects before they have been completely written.  In case
       of object writing error, DECADE-compatible server SHOULD be able
       to respond to the reading DECADE-compatible client with error
       condition indicating that the object writing is failed.

   RATIONALE:  Some Target Applications (in particular, P2P streaming)
       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 in the situation that
       is described in Section 4.1.2.2 or Section 4.1.3.1, it need not
       generate a response.

5.6.  Hints concerning usage of written data  Writing model

   REQUIREMENT(S):  DECADE MAY allow writers of new objects to indicate
       specific hints concerning how the objects are expected to be used
       (e.g., access frequency or time-to-live).

   RATIONALE:  Different Target Applications may have different usage
       patterns for objects written to in-network storage.  For example,
       a P2P live streaming application may indicate to a DECADE server
       that the objects are expected to have a short time-to-live, but
       read frequently.  The DECADE  A DECADE-compatible server may then opt to persist the
       objects in memory instead of in disk.

5.7.  Writing model

   REQUIREMENT(S):  DECADE storage MUST provide at least a
       writing model (while writing an object) that appends data to data
       already written.

   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
       DECADE-compatible server in multiple packets.  To keep
       implementation simple, the DECADE DECADE-compatible server 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 MUST NOT overwrite ranges of the
       object that have already been written).

5.8.

5.7.  Storage Status

   REQUIREMENT(S):  A DECADE client DECADE-compatible server MUST be able to read current respond
       resource usage (including list of written data objects), resource
       quotas, and access permissions for its in-network storage.  The
       returned information resource quotas.  A minimum set of storage
       status supported by DECADE-compatible server MUST include
       resource usage resulting from the client's own usage (including
       list of written data objects) and usage by other clients that
       have been authorized to read/write objects or open connections to on that client's
       storage.  DECADE protocol(s)  A DECADE-compatible server MUST support the ability
       for a DECADE client to read aggregated resource usage information
       (across all other clients be able to which it has authorized access), and
       MAY support authenticate
       the ability to request this information for each
       other authorized client. request.

   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 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 to better allocate them to remote clients.  Due to
       scalability issues, it is not required that DECADE support
       returning usage information broken down by each remote client
       which has been authorized access, but this feature may be useful
       in certain deployment scenarios.

6.  Discovery Requirements

6.1.  Requirements

6.1.1.  Locating DECADE Servers  Support for Clients Behind NATs and Firewalls

   REQUIREMENT(S):  The DECADE Discovery mechanism MUST allow for discovering a DECADE
       Client to identify one or more DECADE Servers to which it is
       authorized to read/write data DECADE-compatible
       server MUST be operable by DECADE-compatible clients operating
       behind NATs and to which it may authorize other
       DECADE Clients to read/write data, or fail if no such DECADE
       Servers are available.

   RATIONALE:  A basic goal of DECADE is to allow DECADE Clients to
       read/write data for access by other DECADE Clients or itself.
       Executing the Discovery process should result in a DECADE Client
       finding a DECADE Server that it can use for these purposes.  It
       is possible that no such DECADE Servers are available.  Note that
       even if a DECADE Client may not successfully locate a DECADE
       Server that fits these criteria, it may still read/write data
       from/to a DECADE Server if authorized by another DECADE Client.

6.1.2.  Support for Clients Behind NATs and Firewalls

   REQUIREMENT(S):  The Discovery mechanism MUST support DECADE Clients
       operating behind NATs and Firewalls without requiring additional
       network support (e.g., Application-level Gateways). Firewalls.

   RATIONALE:  NATs and Firewalls are prevalent in network deployments,
       and it is common for Target Applications that include a DECADE
       Client to be deployed behind these devices.

6.1.3.  Prefer Existing Protocols

   REQUIREMENT(S):  The DECADE Server discovery mechanism SHOULD
       leverage 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.

7.  Future Considerations

   This section enumerates considerations that should be taken into
   account during the DECADE design and implementation.  They have been
   intentionally omitted as requirements since they are either out of
   scope or implementation-dependent.  Nevertheless, enumerating them
   may help to guide future application of the requirements included in
   this document.

7.1.  Fairness

   To provide fairness among users, the in-network storage provider
   should assign resource (e.g., storage, bandwidth, connections) quota
   for users.  This can prevent a small number of clients from occupying
   large amounts of resources on the in-network storage, while others
   starve.

7.2.  Removal of Duplicate Data Objects

   There are actually two possible scenarios.  The first is the case of
   removing duplicates within one particular DECADE server (or logical
   server).  While not a requirement, as it does not impact the
   protocol, a DECADE server may implement internal mechanisms to
   monitor for duplicate objects and use internal mechanisms to prevent
   duplication in internal storage.

   The second scenario is removing duplicates across a distributed set
   of DECADE servers.  DECADE does not explicitly design for this, but
   does offer a redirection mechanism (Section 4.1.3.5) that is one
   primitive that may be used to support this feature in certain
   deployment scenarios.

7.3.  Gaming of the Resource Control Mechanism

   The particular resource control policy communicated by a DECADE
   protocol and enforced by the scheduling system of a DECADE
   implementation may be open to certain gaming by clients. for example
   by specifying many small peers to increase total throughput or
   inciting overload conditions at a DECADE server.  Identifying and
   protecting against all such opportunities for gaming is outside the
   scope of this document, but DECADE protocol(s) prevalent in network deployments,
       and implementations it is common for Target Applications that include a DECADE-
       compatible client to be deployed behind these devices.

6.1.2.  Prefer Existing Protocols

   REQUIREMENT(S):  The mechanism for discovering a DECADE-compatible
       server SHOULD leverage existing mechanisms and protocols wherever
       possible.  No new discovery mechanism will be aware defined unless
       there is enough evidence that opportunities to game no existing mechanism can work.

   RATIONALE:  Existing protocols such as DNS and DHCP are widespread.
       Using existing protocols, or combinations of the system may be
   attempted.

8. protocols that
       have been specified in other contexts, is strictly preferred over
       developing a new discovery protocol.

7.  Security Considerations

   The security model is an important component of DECADE. 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.

8.1.

7.1.  Authentication and Authorization

   DECADE only uses authentication when allowing a particular

   A DECADE-compatible server must authenticate any DECADE-compatible
   client that attempts to access its own storage at a server.  DECADE servers themselves do not
   authenticate other clients which are reading/writing a client's own the in-network storage.  Instead,  DECADE-
   compatible server is not involved in the authorization between DECADE relies on
   clients to authenticate others to
   access its storage, and then communicate the result of that
   authentication to remote clients, or the authorization between DECADE server so that the
   system user and DECADE service provider.  In order to authenticate an
   accessing DECADE client, a DECADE-compatible server may
   implement need to
   accept the necessary authentication and authorization checks.

8.2. referral by another
   DECADE-compatible client.

7.2.  Encrypted Data

   DECADE

   DECADE-compatible Servers provide the ability to write raw data
   objects (subject to any policies instituted by the owner/administrator of the DECADE
   server, which are outside owner/
   administrator of the scope of this document). service provider).  Thus,
   DECADE DECADE-compatible
   clients may opt to encrypt data before it is written transported to the
   DECADE Server.
   server.  However, DECADE itself does DECADE-compatible protocol(s) do not provide
   encryption of data objects other than is that provided by
   Section 4.1.2.1.

9.

7.3.  Protection against Gaming

   The particular resource control policy communicated by DECADE-
   compatible protocol(s) and enforced on DECADE-compatible server may
   be open to certain gaming 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.

8.  IANA Considerations

   There are no IANA considerations with this document.

10.

9.  References

10.1.

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

10.2.  Informative References

   [I-D.ietf-decade-problem-statement]
              Song, H., Zong, N., Yang, Y., and R. Alimi, "DECoupled
              Application Data Enroute (DECADE) Problem Statement",
              draft-ietf-decade-problem-statement-03 (work in progress),
              March 2011.

9.2.  Informative References

   [I-D.ietf-decade-arch]
              Alimi, R., Yang, Y., Rahman, A., Kutscher, D., and H. Liu,
              "DECADE Architecture", draft-ietf-decade-arch-02 (work in
              progress), July 2011.

   [LLSB08]   Levin, D., LaCurts, K., Spring, N., and B. Bhattacharjee,
              "BitTorrent is an Auction: Analyzing and Improving
              BitTorrent's Incentives", SIGCOMM 2008, August 2008.

   [PPLive]   "PPLive", <http://www.pplive.com>.

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, 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
   Polycom, Inc.

   Email: dbryan@ethernot.org

   Yang Richard Yang
   Yale University

   Email: yry@cs.yale.edu

   Richard Alimi
   Google

   Email: ralimi@google.com