Subject: [decade] WG Action: DECoupled Application Data Enroute (decade)

From: IESG Secretary <[email-masked]>
Date: Tue, 27 Apr 2010 11:00:01 -0700 (PDT)

A new IETF working group has been formed in the Applications Area.  For
additional information, please contact the Area Directors or the WG
Chairs.

DECoupled Application Data Enroute (decade)
--------------------------------------------------
Last modified: 2010-04-23

Chair(s):
Haibin Song <[email-masked]>
Richard Woundy <[email-masked]>

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

Applications Area Advisor:
* Alexey Melnikov <[email-masked]>

Mailing Lists:
 General Discussion: [email-masked]
 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 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:

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

---

From: "David A. Bryan" <[email-masked]>
Date: Tue, 27 Apr 2010 18:04:25 -0400

Great to see the group get chartered. Thanks to all the folks who have
worked to see this group come together!

David

On Tue, Apr 27, 2010 at 2:00 PM, IESG Secretary <[email-masked]> wrote:
> _______________________________________________
> decade mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/decade
>

---

From: "Y.J. Gu" <[email-masked]>
Date: Wed, 28 Apr 2010 08:50:04 +0800

Congratulations to all of the contributors and attendees!  Let's keep moving
the work forward.

Regards

Yingjie Gu

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of IESG Secretary
> Sent: Wednesday, April 28, 2010 2:00 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: WG Action: DECoupled Application Data Enroute (decade)
> 
> A new IETF working group has been formed in the Applications 
> Area.  For additional information, please contact the Area 
> Directors or the WG Chairs.
> 
> 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.
> 
> - 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.
> 
> - 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:
> 
> 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 
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce

---

From: Hui Deng <[email-masked]>
Date: Wed, 28 Apr 2010 08:59:27 +0800

Good work, Cong！

-Hui

---

From: "zhangyunfei" <[email-masked]>
Date: Wed, 28 Apr 2010 10:01:48 +0800

Congratulations!

Yunfei

zhangyunfei
2010-04-28

发件人： IESG Secretary
发送时间： 2010-04-28 01:59:21
收件人： [email-masked]
抄送： [email-masked]; [email-masked]
主题： [decade] WG Action: DECoupled Application Data Enroute (decade)

Chair(s):
Haibin  Song   <[email-masked] >
Richard  Woundy   <[email-masked] >

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

Applications  Area  Advisor:
*  Alexey  Melnikov   <[email-masked] >

Mailing  Lists:

Goals  and  Milestones:

---

From: Song Haibin <[email-masked]>
Date: Wed, 28 Apr 2010 10:13:52 +0800

Hi all,
 
I just deleted IESG secretary and ietf-announce from the recipients. 
 
Thanks to all decade guys for getting the WG approved. I would like to
encourage people to write contributions to this WG. Look forward to having
our first WG meeting in Maastricht. 
 
BR,
Haibin

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
zhangyunfei
Sent: Wednesday, April 28, 2010 10:02 AM
To: IESG Secretary; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [decade] WG Action: DECoupled Application Data Enroute (decade)

Congratulations!
 
Yunfei

  _____  

zhangyunfei
2010-04-28

  _____  

发件人： IESG Secretary

Area.    For

Chair(s):

 
Mailing  Lists:

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.

description
 
-  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.

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