Subject: Re: [decade] Updated DECADE Charter

From: "Schmidt, Christian 1. (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 1 Feb 2010 09:47:39 +0100

It would be good to keep focused on the originally planned goals for the
group.

There were a lot of discussions on the list, related to possible, urgent
needed
Or nice to have extenstion with "minor" additional requirements. Lets
take care
Of them in a second step, if needed.

My proposal for the charter text:
"This WG will focus mainly on the protocol between the in-network
storage and 
P2P applications.  The protocol will be focused on P2P applications,
though it 
may also be used in other types of applications with similar protocol
requirements." 

What do you think about this proposal?

BR
Christian Schmidt

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of ext Richard Alimi
Sent: Monday, February 01, 2010 7:02 AM
To: Song Haibin
Cc: [email-masked]
Subject: Re: [decade] Updated DECADE Charter

I agree that doing a survey of every application that might use
in-network 
storage would be quite a daunting task, and that it makes sense to keep
our 
problem narrower.

That said, I was trying to think of a good way to characterize a broader
set 
of applications than "P2P" that we can target, as I do agree that
applications 
such as YouTube and IPTV might have some good use cases.  Might it be
fair to 
say that we can target applications that distribute large data files
that 
might be subdivided in to smaller pieces?

As for wording in the charter, how about something like:

    ... The protocol will be focused on P2P applications and similar
    applications that can subdivide data into smaller pieces for
distribution.

Thoughts?

-- 
Richard Alimi
Department of Computer Science
Yale University

On Friday 29 January 2010 8:35:15 pm Song Haibin wrote:
> I would like to hear other people's opinions. My personal feeling is
that
>  it will get things a little complicated. You have to do a survey of
> resource/access control behaviors for other types of applications
which
>  will possibly use in-network storage, that will broaden the scope a
lot.
> 
> 
> Xie Xie,
> Haibin
> 
> > -----Original Message-----
> > From: Strandberg, Ove (NSN - FI/Espoo)
> > [mailto:[email-masked]]
> > Sent: Friday, January 29, 2010 6:41 PM
> > To: ext Song Haibin; ext Enrico Marocco; Richard Alimi
> > Cc: [email-masked]
> > Subject: RE: [decade] Updated DECADE Charter
> >
> > Hi Haibin,
> >
> > Thanks for your comments.
> >
> > My main concern with P2P as use case is that other
> > interaction towards a network storage other than originating
> > from a P2P client will not be considered. I could easily
> > imagine the benefit of network storage for examples for
> > applications like Spotify, Youtube, IPTV etc.. They can
> > potentially be interedsted in memory utilization too. Thus
> > there are other potential use of a network storage protocol.
> > The relationship of these towards a network storage looks
> > different from a P2P client perspective and designing from
> > only P2P in first step potentially limiting.
> >
> > This use case concern is of principal matter (me thinks) and
> > the charter should reflect this already now. This change does
> > not change the fact that most interest might be on solving
> > the P2P use case, but there are more use cases that should be
> > included in the charter description.
> >
> > Br,
> >
> > +Ove
> >
> > >-----Original Message-----
> > >From: ext Song Haibin [mailto:[email-masked]]
> > >Sent: 29 January, 2010 04:56
> > >To: Strandberg, Ove (NSN - FI/Espoo); 'ext Enrico Marocco';
'Richard
> > >Alimi'
> > >Cc: [email-masked]
> > >Subject: RE: [decade] Updated DECADE Charter
> > >
> > >
> > >Hi Ove,
> > >
> > >Thanks for the good comment. It is very useful if the
> >
> > protocol can be
> >
> > >used by other types of applications. But If you consider other
> > >applications for the first step, you have to incorporate  other
> > >features. For example, you may need replicas in the
> >
> > in-network storage
> >
> > >to guarantee QoS. I prefer to focus on P2P applications
> >
> > initially, but
> >
> > >keep other applications in mind, so that later extensions
> >
> > can be made
> >
> > >to let better integration with other applications.
> > >
> > >Xie Xie,
> > >Haibin
> > >
> > >> -----Original Message-----
> > >> From: [email-masked]
> > >> [mailto:[email-masked]] On Behalf Of Strandberg,
> >
> > Ove (NSN -
> >
> > >> FI/Espoo)
> > >> Sent: Wednesday, January 27, 2010 6:13 PM
> > >> To: ext Enrico Marocco; Richard Alimi
> > >> Cc: [email-masked]
> > >> Subject: Re: [decade] Updated DECADE Charter
> > >>
> > >> Hi all,
> > >>
> > >> At the pre-BOF in Stockholm also other applications than P2P was
> > >> discussed. I probably missed some of the discussion in
> > >
> > >Hiroshima, but
> > >
> > >> I would appriciate shifting focus from P2P intpo more
> >
> > generic use of
> >
> > >> network storage, eg. We should not get into too P2P specific
> > >
> > >solution.
> > >
> > >> The statement:
> > >>
> > >> "The protocol will be focused on P2P applications, though it
> > >
> > >may also
> > >
> > >> be used in other types of applications."
> > >>
> > >> Could be reworked:
> > >>
> > >> "The protocol will be focused on P2P applications, though it
> > >
> > >should be
> > >
> > >> generic to allow usage in other types of applications also."
> > >>
> > >> Br,
> > >>
> > >> +Ove
> > >>
> > >> Ps. I also have background in Network of Information in
> > >
> > >4WARD project.
> > >
> > >> Ds.
> > >>
> > >> >-----Original Message-----
> > >> >From: [email-masked] [mailto:[email-masked]]
On
> > >> >Behalf Of ext Enrico Marocco
> > >> >Sent: 27 January, 2010 12:02
> > >> >To: Richard Alimi
> > >> >Cc: [email-masked]
> > >> >Subject: Re: [decade] Updated DECADE Charter
> > >> >
> > >> >Thanks for putting this together!
> > >> >
> > >> >In general I like text, but one thing I think we should do very
> > >> >carefully is to precisely list what we are sure is missing from
> > >> >existing protocols -- fine grained access and resource
> > >>
> > >> control, right?
> > >>
> > >> >-- as, at the end of the day, that will be the reason why
> > >>
> > >> the IESG may
> > >>
> > >> >decide to charter a new WG. To this extent, I'd prefer to be
more
> > >> >explicit, at the risk of being redundant, e.g. in the last
> > >>
> > >> sentence of
> > >>
> > >> >paragraph 3:
> > >> >
> > >> >  Though there are existing data access protocols (e.g.,
> >
> > HTTP, NFS,
> >
> > >> > WebDAV), they lack capabilities needed when applied in
> > >
> > >this context.
> > >
> > >> >What about replacing it with something along this line?
> > >> >
> > >> >  Though there are existing data access protocols (e.g.,
> >
> > HTTP, NFS,
> >
> > >> > WebDAV), they lack capabilities for fine-grained access and
> > >>
> > >> resource
> > >>
> > >> > control that are essential for today's advanced P2P algorithms.
> > >> >
> > >> >Enrico
> > >> >
> > >> >Richard Alimi wrote:
> > >> >> Hi All,
> > >> >>
> > >> >> We have been working on a new charter with a refined scope and
> > >> >> incorporating past discussion on the mailing list.  It would
be
> > >> >> wonderful to hear comments on the new proposed charter.
> > >> >
> > >> >=============================================================
> > >>
> > >> =========
> > >>
> > >> >> ==
> > >> >>
> > >> >>                    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, this approach poses challenges to both P2P cache
> > >> >
> > >> >vendors and
> > >> >
> > >> >> P2P application developers. For P2P cache vendors, the
> > >> >
> > >> >challenge is to
> > >> >
> > >> >> support a variety of exisiting and evolving protocols. For P2P
> > >> >> applications, closed P2P caching systems limit effective
> > >>
> > >> utilization
> > >>
> > >> >> of in-network storage. Some P2P protocols may be entirely
> > >> >
> > >> >unsupported,
> > >> >
> > >> >> and 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.  Though
> > >>
> > >> there are
> > >>
> > >> >> existing data access protocols (e.g., HTTP, NFS, WebDAV),
> > >> >
> > >> >they lack capabilities needed when applied in this context.
> > >> >
> > >> >> The Working Group (WG) will design and specify a standard
> > >> >
> > >> >protocol for
> > >> >
> > >> >> P2P applications to utilize in-network storage.  The
> > >
> > >protocol will
> > >
> > >> >> include operations for a P2P application to (1) store,
> > >>
> > >> retrieve, and
> > >>
> > >> >> manage data, (2) specify access control for storing and
> > >
> > >retrieving
> > >
> > >> >> data suitable for a P2P environment with peers across multiple
> > >> >> administrative and security domains, and (3) indicate
> > >> >
> > >> >resource control policies for storing and retrieving data.
> > >> >
> > >> >> The WG will leverage existing IETF protocols where possible,
in
> > >> >> particular for storing, retrieving, and managing data.
> > >> >>
> > >> >> This WG will focus mainly on the protocol between the
> >
> > in-network
> >
> > >> >> storage and P2P applications.  The protocol will be
> > >
> > >focused on P2P
> > >
> > >> >> applications, though it may also be used in other types of
> > >> >
> > >> >applications.
> > >> >
> > >> >> 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.
> > >> >>
> > >> >> - A survey document. This document will survey existing
> > >> >
> > >> >related mechanisms
> > >> >
> > >> >>   and protocols (e.g., HTTP, NFS, and WebDAV), and
> >
> > evaluate their
> >
> > >> >>   applicability and effectiveness.
> > >> >>
> > >> >> - A signaling protocol for 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.  Data storage,
> > >> >
> > >> >retrieval, and
> > >> >
> > >> >>   management may be provided by an existing IETF protocol.
> > >> >
> > >> >If the underlying
> > >> >
> > >> >>   protocol does not support certain data management
> > >> >
> > >> >operations, DECADE may
> > >> >
> > >> >>   seek to define such extensions and present them to the
> > >> >
> > >> >respective working
> > >> >
> > >> >>   groups or create an Individual Submission if no active
> > >> >
> > >> >working group exists.
> > >> >
> > >> >>   This group may also create a profile of necessary
> > >> >
> > >> >operations from an
> > >> >
> > >> >>   existing IETF protocol to reduce the complexity and
> > >> >
> > >> >software footprint of a
> > >> >
> > >> >>   compliant implementation.
> > >> >>
> > >> >>   The WG will not limit itself to a single underlying
> > >> >
> > >> >protocol since different
> > >> >
> > >> >>   underlying protocols may have varying implementation costs
> > >> >
> > >> >and performance
> > >> >
> > >> >>   tradeoffs. To keep interoperability manageable, a small
> > >> >
> > >> >number of specific,
> > >> >
> > >> >>   targeted, underlying protocols will be used. NFS and
> > >> >
> > >> >WebDAV are initial
> > >> >
> > >> >>   targets and others may be incorporated with WG consensus.
> > >> >>
> > >> >> - An informational document describing the integration of
> > >> >
> > >> >DECADE with existing
> > >> >
> > >> >>   P2P applications (e.g., integration with BitTorrent).
> > >> >>
> > >> >> The following issues are not considered in the current scope
> > >> >
> > >> >of the WG:
> > >> >> - 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 to deliver content between P2P
> > >> >
> > >> >application and
> > >> >
> > >> >>   in-network storage.
> > >> >>
> > >> >> Goals and Milestones:
> > >> >>
> > >> >> May 2010  Working Group Last Call for problem statement
> >
> > Aug 2010
> >
> > >> >> Submit problem statement to IESG as Informational Aug 2010
> > >>
> > >>  Working
> > >>
> > >> >> Group Last Call for requirements document Feb 2011  Submit
> > >> >> requirements document to IESG as Informational May 2011
> > >> >
> > >> >Working Group
> > >> >
> > >> >> Last Call for survey document Aug 2011  Working Group Last
> > >>
> > >> Call for
> > >>
> > >> >> in-network storage access protocol Aug 2011  Submit survey
> > >> >
> > >> >document to
> > >> >
> > >> >> IESG as Informational Nov 2011  Submit in-network
> >
> > storage access
> >
> > >> >> protocol to IESG as Proposed
> > >> >>           Standard
> > >> >
> > >> >=============================================================
> > >>
> > >> =========
> > >>
> > >> >> ==
> > >> >>
> > >> >> Thanks!
> > >>
> > >> _______________________________________________
> > >> decade mailing list
> > >> [email-masked]
> > >> https://www.ietf.org/mailman/listinfo/decade
> 
_______________________________________________
decade mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/decade

---

From: Song Haibin <[email-masked]>
Date: Mon, 01 Feb 2010 17:27:32 +0800

Hi Christian,

Thanks for your response. See in line.

> From: Schmidt, Christian 1. (NSN - DE/Munich) 
> [mailto:[email-masked]] 
> Sent: Monday, February 01, 2010 4:48 PM
> To: ext Richard Alimi; Song Haibin
> Cc: [email-masked]
> It would be good to keep focused on the originally planned 
> goals for the group.
> 

Agree.

> There were a lot of discussions on the list, related to 
> possible, urgent needed Or nice to have extenstion with 
> "minor" additional requirements. Lets take care Of them in a 
> second step, if needed.
> 

Agree too. We can leave the minor additional requirements to when we design
the control protocol.

> "This WG will focus mainly on the protocol between the 
> in-network storage and P2P applications.  The protocol will 
> be focused on P2P applications, though it may also be used in 
> other types of applications with similar protocol requirements." 
> 

Thanks and I like it very much : )

Xie Xie,
Haibin

> [mailto:[email-masked]] On Behalf Of ext Richard Alimi
> I agree that doing a survey of every application that might 
> use in-network storage would be quite a daunting task, and 
> that it makes sense to keep our problem narrower.
> 
> That said, I was trying to think of a good way to 
> characterize a broader set of applications than "P2P" that we 
> can target, as I do agree that applications such as YouTube 
> and IPTV might have some good use cases.  Might it be fair to 
> say that we can target applications that distribute large 
> data files that might be subdivided in to smaller pieces?
> 
>     applications that can subdivide data into smaller pieces 
> for distribution.
> 
> Thoughts?
> 
> --
> Richard Alimi
> > > My main concern with P2P as use case is that other interaction 
> > > towards a network storage other than originating from a 
> P2P client 
> > > will not be considered. I could easily imagine the benefit of 
> > > network storage for examples for applications like 
> Spotify, Youtube, 
> > > IPTV etc.. They can potentially be interedsted in memory 
> utilization 
> > > too. Thus there are other potential use of a network storage 
> > > protocol.
> different 
> > > from a P2P client perspective and designing from only P2P 
> in first 
> > > step potentially limiting.
> > >
> > > This use case concern is of principal matter (me thinks) and the 
> > > charter should reflect this already now. This change does 
> not change 
> > > the fact that most interest might be on solving the P2P use case, 
> > > but there are more use cases that should be included in 
> the charter 
> > > description.
> > >
> > > Br,
> > >
> > > +Ove
> > >