[secdir] [New-work] WG Review: DECoupled Application Data Enroute (decade)

[IESG Secretary <[e-mail]>]

A new IETF working group has been proposed in the Applications Area.  The
IESG has not made any determination as yet. The following draft charter
was submitted, and is provided for informational purposes only. Please
send your comments to the IESG mailing list ([e-mail]) by Tuesday,
April 20, 2010.               
                         

DECoupled Application Data Enroute (decade)
--------------------------------------------------
Current Status: Proposed Working Group

Last modified: 2010-03-26

Chair(s):
 TBD

Applications Area Director(s):
 * Alexey Melnikov <[e-mail]>
 * Peter Saint-Andre <[e-mail]>

Applications Area Advisor:
 * Alexey Melnikov <[e-mail]>

Mailing Lists:
 General Discussion: [e-mail]
 To Subscribe: https://www.ietf.org/mailman/listinfo/decade
 Archive:
http://www.ietf.org/mail-archive/web/decade/current/maillist.html

Description of Working Group:

Peer-to-Peer (P2P) applications, including both P2P streaming and P2P
file-sharing applications, make up a large fraction of traffic in
the Internet today. One way to reduce access network and/or cross-domain
bandwidth usage by P2P applications is to introduce storage capabilities
in the networks. Allowing P2P applications to store and retrieve data
from inside networks can reduce traffic on the last-mile uplink, as
well as backbone and transit links.

Existing P2P caches often implement the specific P2P application
protocols to operate transparently or act as super peers to provide
in-network storage. However, it is challenging for P2P cache vendors to
support a variety of evolving protocols. Also, for P2P applications,
closed P2P caching systems limit effective utilization of in-network
storage. Some P2P protocols may be entirely unsupported by a particular
caching system. Additionally, applications may be better-equipped to
decide how in-network storage is used to meet their specific
requirements (e.g., data placement, access control and resource
control).

Both of these challenges can be effectively addressed by using an open,
standard protocol to access in-network storage. P2P applications can
store and retrieve content in the in-network storage, as well as control
resources (e.g., bandwidth, connections) consumed by peers in a P2P
application. As a simple example, a peer can choose to store content in
the in-network storage, and direct other peers to retrieve from that
location, reducing last-mile link usage. Furthermore, since a P2P
client may have multiple peers, it can control resources used by each
peer to store and retrieve content. Though there are existing data
access protocols (e.g., HTTP, NFS, WebDAV), they might be lacking
capabilities for fine-grained access and resource control (e.g.,
bandwidth and connections) that are essential for today's advanced P2P
applications.

The Working Group (WG) will have three primary tasks. First, the WG will
identify target applications to appropriately scope the problem and
requirements. P2P applications are the primary target, but suitability
to other applications with similar requirements may be considered
depending on additional complexity required to support such
applications.

Second, the WG will identify the requirements to enable target
applications to utilize in-network storage. Requirements will include
the ability for an application to (1) store, retrieve, and manage data,
(2) indicate access control policies for storing and retrieving data
suitable to an environment with users across multiple administrative and
security domains (e.g., in a P2P environment), and (3) indicate resource
control policies for storing and retrieving data.

Third, the WG will develop an architecture within which the DECADE
protocol can be specified. This architecture will identify DECADE's
relationship to existing IETF protocols and where (if any) new protocol
is needed or extensions to existing protocols need to be made. The
architecture will not specify a protocol or extension; if development of
a new protocol is needed, the WG will seek to recharter for this purpose
or might ask an existing WG to work on such extensions.

The WG will focus on the following work items:

- A "problem statement" document. This document provides a description
of the problem and common terminology.

- A requirements document. This document lists the requirements for the
in-network storage service (e.g., supported operations) and the
protocol to support it. The service will include storing, retrieving,
and managing data as well as specifying both access control and
resource control policies in the in-network storage pertaining to that
data.

- A survey document. This document will survey existing related
mechanisms and protocols (e.g., HTTP, NFS, and WebDAV), and evaluate
their applicability to DECADE.

- An architecture document. This document will identify DECADE's
relationship with existing IETF protocols. Existing protocols will be
used wherever possible and appropriate to support DECADE's
requirements. In particular, data storage, retrieval, and management
may be provided by an existing IETF protocols. The WG will not limit
itself to a single data transport protocol since different protocols
may have varying implementation costs and performance tradeoffs.
However, to keep interoperability manageable, a small number of
specific, targeted, data transport protocols will be identified and
used.

- An document describing the integration of DECADE with existing P2P
applications (e.g., integration with BitTorrent).

If new protocol development (and hence, rechartering) is deemed
necessary, it is not expected that all work items will be ready for IESG
review by that point. However, WG consensus must show that documents
directing eventual protocol development (Requirements and Architecture
document) have stabilized. This permits adjustments to such documents as
necessary to maintain consistency as protocol development is done.

The following issues are considered out-of-scope for the WG:

- Implementation of policies regarding copyright-protected or illegal
content. For example, one possibility is that that an in-network
storage system may have system-wide ingress and egress filters to
implement policies related to copyrighted and illegal content. This
is outside the scope of this working group.

- Locating the "best" in-network storage location from which to retrieve
content if there are more than one location can provide the same
content.

- Developing a new protocol for data transport between P2P applications
and in-network storage.

Goals and Milestones:

Aug 2010 Working Group Last Call for Problem Statement
Nov 2010 Submit Problem Statement to IESG as Informational
Nov 2010 Working Group Last Call for Survey document
Feb 2011 Submit Survey document to IESG as Informational
Feb 2011 Working Group Last Call for Requirements document
Feb 2011 Working Group Last Call for Architecture document
Mar 2011 Identify need for rechartering
May 2011 Submit Requirements document to IESG as Informational
Jul 2011 Submit Architecture document to IESG as Informational
_______________________________________________
New-work mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/new-work