Subject: [decade] Updated DECADE Charter again

From: Song Haibin <[email-masked]>
Date: Wed, 10 Mar 2010 22:25:11 +0800

Hi all,

Here is the newly updated charter by the efforts of many guys. The most important change is that we change the target from protocol development to requirements and use cases. But we may have a chance to recharter the WG to develop a IAP protocol when the requirements and analysis work are solid in the near future. Of course, comments are much appreciated!

DECoupled Application Data Enroute

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 currently lack capabilities for fine-grained access and resource control 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; if development of a new protocol is needed, the WG will seek to recharter for this purpose.

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 have entered Working Group Last Call 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  Identify need for rechartering 
Feb 2011  Working Group Last Call for Survey document 
May 2011  Submit Survey document to IESG as Informational 
May 2011  Working Group Last Call for Requirements document 
Aug 2011  Submit Requirements document to IESG as Informational 
Aug 2011  Working Group Last Call for Architecture document 
Nov 2011  Submit Architecture document to IESG as Informational

BR,
Haibin

---

From: "zhangyunfei" <[email-masked]>
Date: Thu, 11 Mar 2010 09:40:45 +0800

Good job!Some comments are as follows:
1)Para3,the exact job of access and resource control is preferred to be explicit.
2)Para7,
"An  document  describing  the  integration  of  DECADE  with  existing  P2P  applications  (e.g.,  integration  with  BitTorrent)."I don't understand well what the document goes.

Overall this is a clear proposal.Thanks.

BR
Yunfei

zhangyunfei
2010-03-11

发件人： Song Haibin
发送时间： 2010-03-10 22:41:13
收件人： decade
抄送： 
主题： [decade] Updated DECADE Charter again

Hi  all,

Goals  and  Milestones:

BR,
Haibin

_______________________________________________
decade  mailing  list
[email-masked]
https://www.ietf.org/mailman/listinfo/decade

---

From: Song Haibin <[email-masked]>
Date: Thu, 11 Mar 2010 10:24:48 +0800

Thanks for your quick response, Yunfei.
 
We already have examples for the parameters(e.g. bandwidth, connections) for
resource control among the charter text. Access control is about which peer
is authorized to access what content.
 
The integration document is an informational document about how the existing
P2P applications(just take one or two for example) use DECADE for their
content distribution.
 
Hope this clarification helps.

Xie Xie,
Haibin

  _____  

From: zhangyunfei [mailto:[email-masked]] 
Sent: Thursday, March 11, 2010 9:41 AM
To: Song Haibin; decade
Subject: Re: [decade] Updated DECADE Charter again

Good job!Some comments are as follows:
1)Para3,the exact job of access and resource control is preferred to be
explicit.
2)Para7,
"An  document  describing  the  integration  of  DECADE  with  existing  P2P
applications  (e.g.,  integration  with  BitTorrent)."I don't understand
well what the document goes.

BR
Yunfei

  _____  

zhangyunfei
2010-03-11

  _____  

发件人： Song Haibin

Hi  all,
 
Here  is  the  newly  updated  charter  by  the  efforts  of  many  guys.
The  most  important  change  is  that  we  change  the  target  from
protocol  development  to  requirements  and  use  cases.  But  we  may
have  a  chance  to  recharter  the  WG  to  develop  a  IAP  protocol  when
the  requirements  and  analysis  work  are  solid  in  the  near  future.
Of  course,  comments  are  much  appreciated!

 
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  currently  lack
capabilities  for  fine-grained  access  and  resource  control  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;  if  development
of  a  new  protocol  is  needed,  the  WG  will  seek  to  recharter  for
this  purpose.

-  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  have
entered  Working  Group  Last  Call  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.

-  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:

BR,
Haibin

---

From: Richard Alimi <[email-masked]>
Date: Thu, 18 Mar 2010 13:52:37 -0400

Hi All,

The following is an updated of the charter with a few revisions, including a 
revised timeline and updated language concerning the relationship between WG 
consensus for the requirements and architecture documents and rechartering (if 
necessary).

==============================================================

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.

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

- 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

==============================================================

-- 
Richard Alimi
Department of Computer Science
Yale University

---

From: Lars Eggert <[email-masked]>
Date: Thu, 18 Mar 2010 12:03:33 -0700

Hi,

since I had some reservations about earlier charter proposals, let me say that I'm much happier with the latest revisions.

Lars

---

From: "Woundy, Richard" <[email-masked]>
Date: Thu, 18 Mar 2010 16:16:26 -0400

Thanks, Richard. I've updated the agenda to point to *this* version of
the charter.

http://www.ietf.org/proceedings/10mar/agenda/decade.txt

-- Rich

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Richard Alimi
Sent: Thursday, March 18, 2010 1:53 PM
To: [email-masked]
Subject: Re: [decade] Updated DECADE Charter again

Hi All,

The following is an updated of the charter with a few revisions,
including a 
revised timeline and updated language concerning the relationship
between WG 
consensus for the requirements and architecture documents and
rechartering (if 
necessary).

Goals and Milestones:

---

From: Richard Alimi <[email-masked]>
Date: Thu, 18 Mar 2010 16:45:01 -0400

Hi Lars,

Great! Thank you very much and we look forward to the session next Friday. It 
would also be great to get feedback from others who had also commented and 
helped with the prior version of the charter.

On Thursday 18 March 2010 3:03:33 pm Lars Eggert wrote:
> Hi,
> 
> since I had some reservations about earlier charter proposals, let me say
> that I'm much happier with the latest revisions.
> 
> Lars
> 
> > including a revised timeline and updated language concerning the
> > relationship between WG consensus for the requirements and architecture
> > documents and rechartering (if necessary).
> >

---

From: "Schmidt, Christian 1. (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 19 Mar 2010 12:42:04 +0100

Hi Richard,

> > depending on additional complexity required to support such

What application do you have in mind?
Is it possible to narrow the scope, related to the planned applications?
Will the list be included in the problem statement, the requirement
draft or the survey document?

BR
Christian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of ext Richard Alimi
Sent: Thursday, March 18, 2010 9:45 PM
To: Lars Eggert
Cc: [email-masked]
Subject: Re: [decade] Updated DECADE Charter again

Hi Lars,

Great! Thank you very much and we look forward to the session next
Friday. It 
would also be great to get feedback from others who had also commented
and 
helped with the prior version of the charter.

> > documents and rechartering (if necessary).
P2P
> > Both of these challenges can be effectively addressed by using an
open,
> > the ability for an application to (1) store, retrieve, and manage
data,
> > relationship to existing IETF protocols and where (if any) new
protocol
> > - A "problem statement" document. This document provides a
description
> > - A requirements document. This document lists the requirements for
the
> >  protocol to support it. The service will include storing,
retrieving,
> >  mechanisms and protocols (e.g., HTTP, NFS, and WebDAV), and
evaluate
> >  relationship with existing IETF protocols.  Existing protocols will
be
> >  requirements.  In particular, data storage, retrieval, and
management
> >  implement policies related to copyrighted and illegal content.
This
> > - Locating the "best" in-network storage location from which to
retrieve
> > - Developing a new protocol for data transport between P2P
applications

---

From: Richard Alimi <[email-masked]>
Date: Fri, 19 Mar 2010 09:04:37 -0400

Hi Christian,

On Friday 19 March 2010 7:42:04 am Schmidt, Christian 1. (NSN - DE/Munich) 
wrote:
> > > The Working Group (WG) will have three primary tasks. First, the WG
> 
> will
> 
> > > requirements. P2P applications are the primary target, but
> 
> suitability
> 

We do not have any specific ones in mind, but the objective here was to allow 
other applications to be put on the table, such as suggested in Section 2.1 of 
draft-ohlman-decade-add-use-cases-reqs-00. Since the goal of the WG would be 
to define the architecture for DECADE, I personally think it is fair to allow 
consideration of other use cases.  However, I believe the specific targets 
should be decided relatively early on (certainly before any necessary 
rechartering for protocol development).

That said, I believe we still must be careful: the WG would need to weigh the 
additional complexity required to meet such additional use cases. We wish to 
avoid creating a general-purpose system that is usable for arbitrary 
applications.

> Is it possible to narrow the scope, related to the planned applications?

This is a good question.  One possibility is the following: Any application 
that is considered should have the same overall goal and workload 
characteristics as P2P (namely, content distribution), and the ability to 
implement tasks such as searching, redirection, and replication within the 
application itself (instead of relying on in-network storage for such 
services).  That is, we are not talking about some "cloud storage" service 
here.

> draft or the survey document?

My feeling is that the target applications should be put in the problem 
statement.

Thanks for the comments!