draft-ietf-decade-reqs-04.txt   draft-ietf-decade-reqs-05.txt 
DECADE Y. Gu DECADE Y. Gu
Internet-Draft Huawei Internet-Draft Huawei
Intended status: Informational D. Bryan Intended status: Informational D. Bryan
Expires: March 31, 2012 Polycom, Inc. Expires: May 3, 2012 Polycom, Inc.
Y. Yang Y. Yang
Yale University Yale University
R. Alimi R. Alimi
Google Google
September 28, 2011 October 31, 2011
DECADE Requirements DECADE Requirements
draft-ietf-decade-reqs-04 draft-ietf-decade-reqs-05
Abstract Abstract
The target of DECoupled Application Data Enroute (DECADE) is to The target of DECoupled Application Data Enroute (DECADE) is to
provide an open and standard in-network storage system for provide an open and standard in-network storage system for
applications, primarily P2P (peer-to-peer) applications, to store, applications, primarily P2P (peer-to-peer) applications, to store,
retrieve and manage their data. This draft enumerates and explains retrieve and manage their data. This draft enumerates and explains
requirements, not only for storage and retrieval, but also for data requirements, not only for storage and retrieval, but also for data
management, access control and resource control, that should be management, access control and resource control, that should be
considered during the design and implementation of a DECADE system. considered during the design and implementation of a DECADE system.
skipping to change at page 2, line 13 skipping to change at page 2, line 13
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 31, 2012. This Internet-Draft will expire on May 3, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology and Concepts . . . . . . . . . . . . . . . . . . . 5 2. Terminology and Concepts . . . . . . . . . . . . . . . . . . . 6
3. Requirements Structure . . . . . . . . . . . . . . . . . . . . 6 3. Requirements Structure . . . . . . . . . . . . . . . . . . . . 6
4. Protocol Requirements . . . . . . . . . . . . . . . . . . . . 7 4. Protocol Requirements . . . . . . . . . . . . . . . . . . . . 7
4.1. Overall Protocol Requirements . . . . . . . . . . . . . . 7 4.1. Overall Protocol Requirements . . . . . . . . . . . . . . 7
4.1.1. Connectivity Concerns . . . . . . . . . . . . . . . . 7 4.1.1. Connectivity Concerns . . . . . . . . . . . . . . . . 7
4.1.1.1. NATs and Firewalls . . . . . . . . . . . . . . . . 7 4.1.1.1. NATs and Firewalls . . . . . . . . . . . . . . . . 7
4.1.1.2. Connections to Clients . . . . . . . . . . . . . . 7 4.1.1.2. Connections to Clients . . . . . . . . . . . . . . 7
4.1.2. Security . . . . . . . . . . . . . . . . . . . . . . . 7 4.1.2. Security . . . . . . . . . . . . . . . . . . . . . . . 8
4.1.2.1. Secure Transport . . . . . . . . . . . . . . . . . 7 4.1.2.1. Secure Transport . . . . . . . . . . . . . . . . . 8
4.1.3. Error and Failure Conditions . . . . . . . . . . . . . 8 4.1.3. Error and Failure Conditions . . . . . . . . . . . . . 8
4.1.3.1. Overload Condition . . . . . . . . . . . . . . . . 8 4.1.3.1. Overload Condition . . . . . . . . . . . . . . . . 8
4.1.3.2. Insufficient Resources . . . . . . . . . . . . . . 8 4.1.3.2. Insufficient Resources . . . . . . . . . . . . . . 8
4.1.3.3. Unavailable and Deleted Data . . . . . . . . . . . 8 4.1.3.3. Unavailable and Deleted Data . . . . . . . . . . . 9
4.1.3.4. Insufficient Permissions . . . . . . . . . . . . . 9 4.1.3.4. Insufficient Permissions . . . . . . . . . . . . . 9
4.1.3.5. Redirection . . . . . . . . . . . . . . . . . . . 9 4.1.3.5. Redirection . . . . . . . . . . . . . . . . . . . 9
4.2. Transfer and Latency Requirements . . . . . . . . . . . . 9 4.2. Transfer and Latency Requirements . . . . . . . . . . . . 9
4.2.1. Low-Latency Access . . . . . . . . . . . . . . . . . . 9 4.2.1. Low-Latency Access . . . . . . . . . . . . . . . . . . 9
4.2.2. Data Object Size . . . . . . . . . . . . . . . . . . . 10 4.2.2. Data Object Size . . . . . . . . . . . . . . . . . . . 10
4.2.3. Communication among DECADE Servers . . . . . . . . . . 10 4.2.3. Communication among DECADE Servers . . . . . . . . . . 10
4.3. Data Access Requirements . . . . . . . . . . . . . . . . . 11 4.3. Data Access Requirements . . . . . . . . . . . . . . . . . 11
4.3.1. Reading/Writing Own Storage . . . . . . . . . . . . . 11 4.3.1. Reading/Writing Own Storage . . . . . . . . . . . . . 11
4.3.2. Access by Other Users . . . . . . . . . . . . . . . . 11 4.3.2. Access by Other Users . . . . . . . . . . . . . . . . 11
4.3.3. Negotiable Data Transport Protocol . . . . . . . . . . 11 4.3.3. Negotiable Data Transport Protocol . . . . . . . . . . 11
skipping to change at page 3, line 50 skipping to change at page 3, line 50
4.6.1. Multiple Applications . . . . . . . . . . . . . . . . 14 4.6.1. Multiple Applications . . . . . . . . . . . . . . . . 14
4.6.2. Per-Remote-Client, Per-Data Control . . . . . . . . . 14 4.6.2. Per-Remote-Client, Per-Data Control . . . . . . . . . 14
4.6.3. Server Involvement . . . . . . . . . . . . . . . . . . 15 4.6.3. Server Involvement . . . . . . . . . . . . . . . . . . 15
4.7. Authorization . . . . . . . . . . . . . . . . . . . . . . 15 4.7. Authorization . . . . . . . . . . . . . . . . . . . . . . 15
4.7.1. Per-Remote-Client, Per-Data Read Access . . . . . . . 15 4.7.1. Per-Remote-Client, Per-Data Read Access . . . . . . . 15
4.7.2. Per-User Write Access . . . . . . . . . . . . . . . . 15 4.7.2. Per-User Write Access . . . . . . . . . . . . . . . . 15
4.7.3. Default Access Permissions . . . . . . . . . . . . . . 16 4.7.3. Default Access Permissions . . . . . . . . . . . . . . 16
4.7.4. Authorization Checks . . . . . . . . . . . . . . . . . 16 4.7.4. Authorization Checks . . . . . . . . . . . . . . . . . 16
4.7.5. Cryptographic Credentials . . . . . . . . . . . . . . 16 4.7.5. Cryptographic Credentials . . . . . . . . . . . . . . 16
4.7.6. Server Involvement . . . . . . . . . . . . . . . . . . 16 4.7.6. Server Involvement . . . . . . . . . . . . . . . . . . 16
4.7.7. Protocol Reuse . . . . . . . . . . . . . . . . . . . . 16 4.7.7. Protocol Reuse . . . . . . . . . . . . . . . . . . . . 17
4.8. Non-Requirements . . . . . . . . . . . . . . . . . . . . . 17 4.8. Non-Requirements . . . . . . . . . . . . . . . . . . . . . 17
4.8.1. Application-defined Properties and Metadata . . . . . 17 4.8.1. Application-defined Properties and Metadata . . . . . 17
5. Storage Requirements . . . . . . . . . . . . . . . . . . . . . 17 5. Storage Requirements . . . . . . . . . . . . . . . . . . . . . 17
5.1. Immutable Data . . . . . . . . . . . . . . . . . . . . . . 17 5.1. Immutable Data . . . . . . . . . . . . . . . . . . . . . . 17
5.2. Explicit Deletion of Data . . . . . . . . . . . . . . . . 17 5.2. Explicit Deletion of Data . . . . . . . . . . . . . . . . 18
5.3. Multiple writing . . . . . . . . . . . . . . . . . . . . . 18 5.3. Multiple writing . . . . . . . . . . . . . . . . . . . . . 18
5.4. Multiple reading . . . . . . . . . . . . . . . . . . . . . 18 5.4. Multiple reading . . . . . . . . . . . . . . . . . . . . . 18
5.5. Reading before completely written . . . . . . . . . . . . 18 5.5. Reading before completely written . . . . . . . . . . . . 18
5.6. Hints concerning usage of written data . . . . . . . . . . 18 5.6. Hints concerning usage of written data . . . . . . . . . . 19
5.7. Writing model . . . . . . . . . . . . . . . . . . . . . . 19 5.7. Writing model . . . . . . . . . . . . . . . . . . . . . . 19
5.8. Storage Status . . . . . . . . . . . . . . . . . . . . . . 19 5.8. Storage Status . . . . . . . . . . . . . . . . . . . . . . 19
6. Discovery Requirements . . . . . . . . . . . . . . . . . . . . 20 6. Discovery Requirements . . . . . . . . . . . . . . . . . . . . 20
6.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 20 6.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 20
6.1.1. Locating DECADE Servers . . . . . . . . . . . . . . . 20 6.1.1. Locating DECADE Servers . . . . . . . . . . . . . . . 20
6.1.2. Support for Clients Behind NATs and Firewalls . . . . 20 6.1.2. Support for Clients Behind NATs and Firewalls . . . . 20
6.1.3. Prefer Existing Protocols . . . . . . . . . . . . . . 20 6.1.3. Prefer Existing Protocols . . . . . . . . . . . . . . 20
7. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 20 7. Future Considerations . . . . . . . . . . . . . . . . . . . . 21
7.1. Non-DECADE Internal Protocols . . . . . . . . . . . . . . 20 7.1. Fairness . . . . . . . . . . . . . . . . . . . . . . . . . 21
7.2. Fairness . . . . . . . . . . . . . . . . . . . . . . . . . 21 7.2. Removal of Duplicate Data Objects . . . . . . . . . . . . 21
7.3. Removal of Duplicate Data Objects . . . . . . . . . . . . 21 7.3. Gaming of the Resource Control Mechanism . . . . . . . . . 21
7.4. Gaming of the Resource Control Mechanism . . . . . . . . . 21
8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21
8.1. Authentication and Authorization . . . . . . . . . . . . . 22 8.1. Authentication and Authorization . . . . . . . . . . . . . 22
8.2. Encrypted Data . . . . . . . . . . . . . . . . . . . . . . 22 8.2. Encrypted Data . . . . . . . . . . . . . . . . . . . . . . 22
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
10.1. Normative References . . . . . . . . . . . . . . . . . . . 22 10.1. Normative References . . . . . . . . . . . . . . . . . . . 22
10.2. Informative References . . . . . . . . . . . . . . . . . . 22 10.2. Informative References . . . . . . . . . . . . . . . . . . 22
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 23 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
skipping to change at page 5, line 42 skipping to change at page 5, line 42
This document enumerates the requirements to enable target This document enumerates the requirements to enable target
applications to utilize in-network storage. In this context, using applications to utilize in-network storage. In this context, using
storage resources includes not only basic capabilities such as storage resources includes not only basic capabilities such as
writing, reading, and managing data, but also controlling access for writing, reading, and managing data, but also controlling access for
particular remote clients with which it is sharing data. particular remote clients with which it is sharing data.
Additionally, we also consider controlling the resources used by Additionally, we also consider controlling the resources used by
remote clients when they access data as an integral part of utilizing remote clients when they access data as an integral part of utilizing
the network storage. the network storage.
This document discusses requirements pertaining to DECADE
protocol(s). In certain deployments, several logical in-network
storage systems could be deployed (e.g., within the same
administrative domain). These in-network storage systems can
communicate and transfer data through internal or non-standard
communication messages that are outside of the scope of these
requirements, but they SHOULD use DECADE protocol(s) when
communicating with other DECADE-capable in-network storage systems.
2. Terminology and Concepts 2. Terminology and Concepts
This document uses terms defined in This document uses terms defined in
[I-D.ietf-decade-problem-statement]. [I-D.ietf-decade-problem-statement].
This document also defines additional terminology: This document also defines additional terminology:
Target Application: An application (typically installed at end-hosts) Target Application: An application (typically installed at end-hosts)
with the ability to explicitly control usage of network and/or with the ability to explicitly control usage of network and/or
storage resources to deliver content to a large number of users. storage resources to deliver content to a large number of users.
skipping to change at page 6, line 30 skipping to change at page 6, line 40
Target Applications to make use of storage within the network, Target Applications to make use of storage within the network,
leaving specific storage system considerations to the implementation leaving specific storage system considerations to the implementation
of the DECADE servers as much as possible. For this reason, we have of the DECADE servers as much as possible. For this reason, we have
divided the requirements into two primary categories: divided the requirements into two primary categories:
o Protocol Requirements: Protocol requirements for Target o Protocol Requirements: Protocol requirements for Target
Applications to make use of in-network storage within their own Applications to make use of in-network storage within their own
data dissemination schemes. Development of these requirements is data dissemination schemes. Development of these requirements is
guided by a study of data access, search and management guided by a study of data access, search and management
capabilities used by Target Applications. These requirements may capabilities used by Target Applications. These requirements may
be met by a combination of existing protocols and new protocols to be met by a combination of existing protocols and new protocols.
be defined within the DECADE Working Group.
o Storage Requirements: Functional requirements necessary for the o Storage Requirements: Functional requirements necessary for the
back-end storage system employed by the DECADE server. back-end storage system employed by the DECADE server.
Development of these requirements is guided by a study of the data Development of these requirements is guided by a study of the data
access patterns used by Target Applications. These requirements access patterns used by Target Applications. These requirements
should be met by the underlying data transport used by DECADE. In should be met by the underlying data transport used by DECADE. In
this document, we use "data transport" to refer to a protocol used this document, we use "data transport" to refer to a protocol used
to read and write data from DECADE in-network storage. to read and write data from DECADE in-network storage.
Note that a third category also enumerates requirements on the Note that a third category also enumerates requirements on the
skipping to change at page 7, line 20 skipping to change at page 7, line 29
4. Protocol Requirements 4. Protocol Requirements
This section details the requirements of DECADE protocol(s). This section details the requirements of DECADE protocol(s).
4.1. Overall Protocol Requirements 4.1. Overall Protocol Requirements
4.1.1. Connectivity Concerns 4.1.1. Connectivity Concerns
4.1.1.1. NATs and Firewalls 4.1.1.1. NATs and Firewalls
REQUIREMENT(S): DECADE SHOULD be usable across firewalls and NAT REQUIREMENT(S): DECADE client to server protocols SHOULD be usable
(Network Address Translation) devices without requiring across firewalls and NAT (Network Address Translation) devices
additional network support (e.g., Application-level Gateways). without requiring additional network support (e.g., Application-
level Gateways).
RATIONALE: Firewalls and NATs are widely used in the Internet today, RATIONALE: Firewalls and NATs are widely used in the Internet today,
both in ISP (Internet Service Provider) and Enterprise networks both in ISP (Internet Service Provider) and Enterprise networks
and by consumers. Deployment of DECADE must not require and by consumers. Deployment of DECADE must not require
modifications to such devices (beyond, perhaps, reconfiguration). modifications to such devices (beyond, perhaps, reconfiguration).
Note that this requirement applies to both any new protocol Note that this requirement applies to both any new protocol
developed by the DECADE Working Group and any data transport used developed by the DECADE Working Group and any data transport used
with DECADE. with DECADE.
4.1.1.2. Connections to Clients 4.1.1.2. Connections to Clients
skipping to change at page 9, line 42 skipping to change at page 10, line 4
RATIONALE: A DECADE server may opt to redirect requests to another RATIONALE: A DECADE server may opt to redirect requests to another
server to support capabilities such as load balancing, or if the server to support capabilities such as load balancing, or if the
implementation decides that another DECADE server is in a better implementation decides that another DECADE server is in a better
position to handle the request due to either its location in the position to handle the request due to either its location in the
network, server status, or other consideration. network, server status, or other consideration.
4.2. Transfer and Latency Requirements 4.2. Transfer and Latency Requirements
4.2.1. Low-Latency Access 4.2.1. Low-Latency Access
REQUIREMENT(S): DECADE SHOULD provide "low-latency" access for REQUIREMENT(S): DECADE SHOULD provide "low-latency" access for
application clients. DECADE MUST allow clients to specify at application clients. DECADE MUST allow clients to specify at
least two classes of services for service: lowest possible least two classes of services: lowest possible latency and
latency and latency non-critical. latency non-critical.
RATIONALE: Some applications may have requirements on delivery time RATIONALE: Some applications may have requirements on delivery time
(e.g., live streaming [PPLive]). The user experience may be (e.g., live streaming [PPLive]). The user experience may be
unsatisfactory if the use of in-network storage results in lower unsatisfactory if the use of in-network storage results in lower
performance than connecting directly to remote clients over a performance than connecting directly to remote clients over a
low-speed, possibly congested uplink. Additionally, the overhead low-speed, possibly congested uplink. Additionally, the overhead
required for control-plane operations in DECADE must not cause required for control-plane operations in DECADE must not cause
the latency to be higher than for a low-speed, possibly congested the latency to be higher than for a low-speed, possibly congested
uplink. While it is impossible to make a guarantee that a system uplink. While it is impossible to make a guarantee that a system
using in-network storage will always outperform a system that using in-network storage will always outperform a system that
skipping to change at page 17, line 33 skipping to change at page 17, line 44
itself, (2) storing metadata inside of the data object, or (3) itself, (2) storing metadata inside of the data object, or (3)
storing metadata in a different data object at the DECADE server. storing metadata in a different data object at the DECADE server.
5. Storage Requirements 5. Storage Requirements
This section details the requirements of the underlying storage used This section details the requirements of the underlying storage used
to support the DECADE protocol(s). to support the DECADE protocol(s).
5.1. Immutable Data 5.1. Immutable Data
REQUIREMENT(S): DECADE MUST provide the ability to manage data REQUIREMENT(S): DECADE MUST only store and manage data objects that
objects that are immutable once they are written to storage. are immutable once they are written to storage.
RATIONALE: Immutable data objects are an important simplification in RATIONALE: Immutable data objects are an important simplification in
DECADE. Reasonable consistency models for updating existing DECADE. Reasonable consistency models for updating existing
objects would significantly complicate implementation (especially objects would significantly complicate implementation (especially
if implementation chooses to replicate data across multiple if implementation chooses to replicate data across multiple
servers). If a user needs to update a resource, it can write a servers). If a user needs to update a resource, it can write a
new resource and then distribute the new resource instead of the new resource and then distribute the new resource instead of the
old one. old one.
5.2. Explicit Deletion of Data 5.2. Explicit Deletion of Data
skipping to change at page 20, line 23 skipping to change at page 20, line 28
authorized to read/write data and to which it may authorize other authorized to read/write data and to which it may authorize other
DECADE Clients to read/write data, or fail if no such DECADE DECADE Clients to read/write data, or fail if no such DECADE
Servers are available. Servers are available.
RATIONALE: A basic goal of DECADE is to allow DECADE Clients to RATIONALE: A basic goal of DECADE is to allow DECADE Clients to
read/write data for access by other DECADE Clients or itself. read/write data for access by other DECADE Clients or itself.
Executing the Discovery process should result in a DECADE Client Executing the Discovery process should result in a DECADE Client
finding a DECADE Server that it can use for these purposes. It finding a DECADE Server that it can use for these purposes. It
is possible that no such DECADE Servers are available. Note that is possible that no such DECADE Servers are available. Note that
even if a DECADE Client may not successfully locate a DECADE even if a DECADE Client may not successfully locate a DECADE
Server that fits these criteria, it may still read/write data a Server that fits these criteria, it may still read/write data
DECADE Server if authorized by another DECADE Client. from/to a DECADE Server if authorized by another DECADE Client.
6.1.2. Support for Clients Behind NATs and Firewalls 6.1.2. Support for Clients Behind NATs and Firewalls
REQUIREMENT(S): The Discovery mechanism MUST support DECADE Clients REQUIREMENT(S): The Discovery mechanism MUST support DECADE Clients
operating behind NATs and Firewalls without requiring additional operating behind NATs and Firewalls without requiring additional
network support (e.g., Application-level Gateways). network support (e.g., Application-level Gateways).
RATIONALE: NATs and Firewalls are prevalent in network deployments, RATIONALE: NATs and Firewalls are prevalent in network deployments,
and it is common for Target Applications that include a DECADE and it is common for Target Applications that include a DECADE
Client to be deployed behind these devices. Client to be deployed behind these devices.
skipping to change at page 20, line 46 skipping to change at page 21, line 5
6.1.3. Prefer Existing Protocols 6.1.3. Prefer Existing Protocols
REQUIREMENT(S): The DECADE Server discovery mechanism SHOULD REQUIREMENT(S): The DECADE Server discovery mechanism SHOULD
leverage existing mechanisms and protocols wherever possible. leverage existing mechanisms and protocols wherever possible.
RATIONALE: Existing protocols such as DNS and DHCP are widespread. RATIONALE: Existing protocols such as DNS and DHCP are widespread.
Using existing protocols, or combinations of the protocols that Using existing protocols, or combinations of the protocols that
have been specified in other contexts, is strictly preferred over have been specified in other contexts, is strictly preferred over
developing a new discovery protocol for DECADE. developing a new discovery protocol for DECADE.
7. Discussion 7. Future Considerations
7.1. Non-DECADE Internal Protocols
Sometimes, several logical in-network storage systems could be This section enumerates considerations that should be taken into
deployed on the same physical network device. In this case, in- account during the DECADE design and implementation. They have been
network storages on the same physical network device can communicate intentionally omitted as requirements since they are either out of
and transfer data through internal communication messages. However scope or implementation-dependent. Nevertheless, enumerating them
in-network storages deployed on different physical network devices may help to guide future application of the requirements included in
SHOULD communicate with DECADE protocol(s). this document.
7.2. Fairness 7.1. Fairness
To provide fairness among users, the in-network storage provider To provide fairness among users, the in-network storage provider
should assign resource (e.g., storage, bandwidth, connections) quota should assign resource (e.g., storage, bandwidth, connections) quota
for users. This can prevent a small number of clients from occupying for users. This can prevent a small number of clients from occupying
large amounts of resources on the in-network storage, while others large amounts of resources on the in-network storage, while others
starve. starve.
7.3. Removal of Duplicate Data Objects 7.2. Removal of Duplicate Data Objects
There are actually two possible scenarios. The first is the case of There are actually two possible scenarios. The first is the case of
removing duplicates within one particular DECADE server (or logical removing duplicates within one particular DECADE server (or logical
server). While not a requirement, as it does not impact the server). While not a requirement, as it does not impact the
protocol, a DECADE server may implement internal mechanisms to protocol, a DECADE server may implement internal mechanisms to
monitor for duplicate objects and use internal mechanisms to prevent monitor for duplicate objects and use internal mechanisms to prevent
duplication in internal storage. duplication in internal storage.
The second scenario is removing duplicates across a distributed set The second scenario is removing duplicates across a distributed set
of DECADE servers. DECADE does not explicitly design for this, but of DECADE servers. DECADE does not explicitly design for this, but
does offer a redirection mechanism (Section 4.1.3.5) that is one does offer a redirection mechanism (Section 4.1.3.5) that is one
primitive that may be used to support this feature in certain primitive that may be used to support this feature in certain
deployment scenarios. deployment scenarios.
7.4. Gaming of the Resource Control Mechanism 7.3. Gaming of the Resource Control Mechanism
The particular resource control policy communicated by a DECADE The particular resource control policy communicated by a DECADE
protocol and enforced by the scheduling system of a DECADE protocol and enforced by the scheduling system of a DECADE
implementation may be open to certain gaming by clients. for example implementation may be open to certain gaming by clients. for example
by specifying many small peers to increase total throughput or by specifying many small peers to increase total throughput or
inciting overload conditions at a DECADE server. Identifying and inciting overload conditions at a DECADE server. Identifying and
protecting against all such opportunities for gaming is outside the protecting against all such opportunities for gaming is outside the
scope of this document, but DECADE protocol(s) and implementations scope of this document, but DECADE protocol(s) and implementations
SHOULD be aware that opportunities to game the system may be SHOULD be aware that opportunities to game the system may be
attempted. attempted.
skipping to change at page 23, line 16 skipping to change at page 23, line 19
"BitTorrent is an Auction: Analyzing and Improving "BitTorrent is an Auction: Analyzing and Improving
BitTorrent's Incentives", SIGCOMM 2008, August 2008. BitTorrent's Incentives", SIGCOMM 2008, August 2008.
[PPLive] "PPLive", <http://www.pplive.com>. [PPLive] "PPLive", <http://www.pplive.com>.
Appendix A. Acknowledgments Appendix A. Acknowledgments
We would also like to thank Haibin Song for substantial contributions We would also like to thank Haibin Song for substantial contributions
to earlier versions of this document. We would also like to thank to earlier versions of this document. We would also like to thank
Reinaldo Penno, Alexey Melnikov, Rich Woundy, Ning Zong, Roni Even, Reinaldo Penno, Alexey Melnikov, Rich Woundy, Ning Zong, Roni Even,
David McDysan, Boerje Ohlman, Dirk Kutscher, Akbar Rahman, Xiao Zhu, David McDysan, Borje Ohlman, Dirk Kutscher, Akbar Rahman, Xiao Zhu,
Yunfei Zhang, and Jin Peng for contributions and general feedback. Yunfei Zhang, and Jin Peng for contributions and general feedback.
Authors' Addresses Authors' Addresses
Yingjie Gu Yingjie Gu
Huawei Huawei
No. 101 Software Avenue No. 101 Software Avenue
Nanjing, Jiangsu Province 210012 Nanjing, Jiangsu Province 210012
P.R.China P.R.China
 End of changes. 24 change blocks. 
41 lines changed or deleted 46 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/