* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Decade Status Pages

Decoupled Application Data Enroute (Concluded WG)
Tsv Area: Zaheduzzaman Sarker, Martin Duke | 2010-Apr-27 — 2012-Sep-20 
Chairs
 
 


2012-06-13 charter

Decoupled Application Data Enroute (decade)
-------------------------------------------

 Charter

 Current Status: Active

 Chairs:
     Haibin Song <haibin.song@huawei.com>
     Richard Woundy <Richard_Woundy@cable.comcast.com>

 Transport Area Directors:
     Wesley Eddy <wes@mti-systems.com>
     Martin Stiemerling <martin.stiemerling@neclab.eu>

 Transport Area Advisor:
     Martin Stiemerling <martin.stiemerling@neclab.eu>

 Tech Advisor:
     Alexey Melnikov <alexey.melnikov@isode.com>

 Mailing Lists:
     General Discussion: decade@ietf.org
     To Subscribe:       https://www.ietf.org/mailman/listinfo/decade
     Archive:            http://www.ietf.org/mail-archive/web/decade/

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 network between hosts running P2P applications. Allowing P2P
    applications to store and retrieve data from inside the network 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). Note that providers of in-network storage may impose their
    own access control or resource usage policies.

    Both of these challenges can be effectively addressed by using open,
    standard protocols 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 is deemed necessary, the WG will be
    rechartered. It is not expected that all work items will be ready for
    IESG review by that point, but 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:

    - Specification of policies regarding copyright-protected or illegal
    content.

    - 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:
  Done     - Working Group Last Call for Problem Statement
  Done     - Submit Problem Statement to IESG as Informational
  Done     - Working Group Last Call for Survey document
  Done     - Submit Survey document to IESG as Informational
  Jul 2011 - Working Group Last Call for Requirements document
  Jul 2011 - Working Group Last Call for Architecture document
  Aug 2011 - Submit Requirements document to IESG as Informational
  Sep 2011 - Identify need for rechartering
  Sep 2011 - Submit Architecture document to IESG as Informational
  Sep 2011 - Working Group Last Call for DECADE Integration Examples
  Dec 2011 - Submit DECADE Integration Examples to IESG as Informational


All charter page changes, including changes to draft-list, rfc-list and milestones:



Generated from PyHt script /wg/decade/charters.pyht Latest update: 24 Oct 2012 16:51 GMT -