Subject: Re: [decade] Updated DECADE Charter

From: Lars Eggert <[email-masked]>
Date: Mon, 1 Feb 2010 12:20:59 +0200

Hi,

On 2010-2-1, at 6:25, Richard Alimi wrote:
> Thanks for the response.  First, I'd like to clarify that we're on the same 
> page in regards to the intended WG scope.  We will indeed re-use existing 
> underlying protocols wherever possible.

there's an assumption here that DECADE will result in a separate protocol, potentially layered in top of existing protocols like NFS or WebDAV. Why are we already convinced that this is what the design would look like?

I can equally well envision an outcome where the DECADE effort results in a BCP that says "here is how you configure one or more NFS (or WebDAV) servers for caching media chunks, and here's how you'd implement cache access in a P2P client." In other words, there wouldn't be a separate protocol but "just" configuration and practices of how to use NFS or WebDAV for what's needed for this deployment case.

> According to the currently-proposed 
> charter, the new WG would be responsible for:
> 
> - Defining the access-control requirements, needed resource-control
>  information, and the necessary management interfaces that would be necessary
>  for scenarios where DECADE would be applied (primarily usage by P2P
>  applications).  These core pieces would be common to any DECADE
>  implementation.

Right. This is similar to what I had as a design counterexample above.

> - Define DECADE to operate over existing underlying protocols. In the charter,
>  we have explicitly mentioned NFS and WebDAV as targets, since both are
>  well-established protocols and each may be applicable in different
>  deployment scenarios.

From what I've seen, this step (DECADE needing to be a separate protocol) is not sufficiently motivated.

> I'm also trying to understand your viewpoint a bit better here.  Are you of 
> the opinion that NFS is the only protocol that should be extended?

Not at all. I'm saying that we have successful storage protocols (NFS, WebDAV) and it's unclear to me that we need a third protocol just for this deployment scenario. I simply haven't seen a conclusive argument for it. 

Lars

---

From: Song Haibin <[email-masked]>
Date: Tue, 02 Feb 2010 17:42:14 +0800

Hi Lars,

I can guess the only difference between us is whether we need a separate
control protocol or extend/configure the existing protocols such like NFS or
WebDAV.

My understanding is that we have many storage access protocols like NFS and
WebDAV, as well as others protocols mentioned in my last email
(http://www.ietf.org/mail-archive/web/decade/current/msg00147.html) such as
SMB, NetWare Core Protocol (NCP), AFP and QFileSvr.400. It is good to reuse
the capabilities defined in these protocols whenever possible. However, it
is not wise to extend each protocol to solve the same problem in DECADE.

> I can equally well envision an outcome where the DECADE 
> effort results in a BCP that says "here is how you configure 
> one or more NFS (or WebDAV) servers for caching media chunks, 
> and here's how you'd implement cache access in a P2P client." 
> In other words, there wouldn't be a separate protocol but 
> "just" configuration and practices of how to use NFS or 
> WebDAV for what's needed for this deployment case.

It's beyond configuration in my mind. DECADE would be applied to multiple
underlying protocols. They should understand the same resource/access
control information in the same way. That's what a standard protocol does.

BR,
Haibin

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Lars Eggert
> Sent: Monday, February 01, 2010 6:21 PM
> To: Richard Alimi
> Cc: [email-masked]
> Subject: Re: [decade] Updated DECADE Charter
> 
> Hi,
> 
> > Thanks for the response.  First, I'd like to clarify that 
> we're on the 
> > same page in regards to the intended WG scope.  We will 
> indeed re-use 
> > existing underlying protocols wherever possible.
> 
> there's an assumption here that DECADE will result in a 
> separate protocol, potentially layered in top of existing 
> protocols like NFS or WebDAV. Why are we already convinced 
> that this is what the design would look like?
> 

> I can equally well envision an outcome where the DECADE 
> effort results in a BCP that says "here is how you configure 
> one or more NFS (or WebDAV) servers for caching media chunks, 
> and here's how you'd implement cache access in a P2P client." 
> In other words, there wouldn't be a separate protocol but 
> "just" configuration and practices of how to use NFS or 
> WebDAV for what's needed for this deployment case.
> 
> > information, and the necessary management interfaces that would be 
> > necessary  for scenarios where DECADE would be applied (primarily 
> > usage by P2P  applications).  These core pieces would be 
> common to any 
> > DECADE  implementation.
> 
> > - Define DECADE to operate over existing underlying 
> protocols. In the 
> > charter,  we have explicitly mentioned NFS and WebDAV as targets, 
> > since both are  well-established protocols and each may be 
> applicable 
> > in different  deployment scenarios.
> 
> From what I've seen, this step (DECADE needing to be a 
> separate protocol) is not sufficiently motivated.
> 
> > I'm also trying to understand your viewpoint a bit better 
> here.  Are 
> > you of the opinion that NFS is the only protocol that 
> should be extended?
> 
> Not at all. I'm saying that we have successful storage 
> protocols (NFS, WebDAV) and it's unclear to me that we need a 
> third protocol just for this deployment scenario. I simply 
> haven't seen a conclusive argument for it. 
> 
> Lars
> 
> 
>

---

From: Lars Eggert <[email-masked]>
Date: Tue, 2 Feb 2010 11:51:34 +0200

Hi,

> control information in the same way. That's what a standard protocol does.

why would DECADE be applied to multiple underlying protocols; where is the benefit? IMO you analyze them all and pick the one with the best match for your deployment case. Then you decide whether you can get by with scenario-speficif usage guidelines, need small extensions, or need to layer something on top.

Lars

---

From: songhaibin 64081 <[email-masked]>
Date: Wed, 03 Feb 2010 00:28:19 +0800

Hi Lars,

> > It's beyond configuration in my mind. DECADE would be applied to 
> multiple> underlying protocols. They should understand the same 
> resource/access> control information in the same way. That's what 
> a standard protocol does.
> 
> why would DECADE be applied to multiple underlying protocols; 
> where is the benefit? IMO you analyze them all and pick the one 
> with the best match for your deployment case. Then you decide 
> whether you can get by with scenario-speficif usage guidelines, 
> need small extensions, or need to layer something on top.
> 

Thanks for your response. Please allow me to give an simple example about why DECADE should be applied to multiple underlying protocols here. Applications such like PPLive may want to use in-network storage to accelerate their media distribution, they have already have a way to identify their media pieces, so what they want is to use a simple RTP protocol for the underlying data transport between clients and in-network storage and use anoth
er protocol (DECADE) to do resource control. Of course, some other applications that already implemented NFS might want to use NFS as the underlying protocol. If we tie DECADE to a specific underlying protocol, there might need much changes for some applications to be modified to support it and it will be hard to intergrate with DECADE (so fail in the real world). 

BR,
Haibin

---

From: Richard Alimi <[email-masked]>
Date: Tue, 2 Feb 2010 18:06:13 -0500

Hi All,

Thank you very much to all who have provided feedback and participated in the 
discussion on the proposed charter. Below is a revised version of the charter 
reflecting the discussion.  We look forward to further comments and feedback. 
Thanks!

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

                   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 existing and evolving protocols. 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.  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 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 policies 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 by other types of applications with similar protocol 
requirements.

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. The underlying protocol will be used wherever possible to support
  DECADE's required operations.  It is assumed that the underlying protocol
  already supports data transport for reading from and writing to in-network
  storage. If the existing underlying protocol does not support certain
  resource 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 DECADE-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:

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

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

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

-- 
Richard Alimi
Department of Computer Science
Yale University

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 2 Feb 2010 18:47:55 -0500

Is it possible to have a step between these two where we narrow down the
candidate protocols for the survey? It might be implied but the wording
leaves the door open for a number of different protocols.

If many protocols meet the requirements one way or another (tweaks,
extensions, etc) the survey document might get quite intense.

Therefore I would suggest some wording around a pre-selection.

Another possibility is to have different surveys based on interest,
volunteers, etc for each protocol. Then the pre-selection is done naturally,
if there is no interest in a certain protocol, then nobody will pick up the
work. 

Thanks,

Reinaldo

---

From: "David A. Bryan" <[email-masked]>
Date: Wed, 3 Feb 2010 13:26:07 -0500

Is what you are suggesting by the different survey documents from
various authors, almost something like "I like protocol AAA, so I
write a document explaining why it meets the requirements better than
XXX and YYY, and might revise it if someone also proposes ZZZ and I
still think AAA is better"?

It's an interesting approach. I understand what you are concerned
about in terms of the growth of a survey document if there are many
viable candidates, but a worry a bit that the approach I paraphrased
above (which might not be quite what you are proposing, so forgive me
if I put words in your mouth) starts to look a good deal like the
proposals for various protocols making use of AAA. Now mind you this
may be fine (we had something similar in P2PSIP with folks proposing
SIP-based and binary encodings), but it seems like it more or less
eliminates the survey document, and instead goes for a "battle of
ideas" approach between possible protocols that could be used (and one
could imagine a clean sheet proposal as well)

I guess I'm a bit torn. If we have many proposals (so far I've only
heard HTTP, WebDav and NFS seriously considered, so not sure I see the
problem yet), the survey document could get large. I guess the big
question is do we really think that a survey document can provide
enough information to the group to determine which protocol to go
with, divorced from actaually trying to design a use the protocol and
see if the proposed protocol/extensions fit the requirements (modulo
several iterations between those two that may be required.)

David

On Tue, Feb 2, 2010 at 6:47 PM, Reinaldo Penno <[email-masked]> wrote:
> _______________________________________________
> decade mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/decade
>

---

From: Reinaldo Penno <[email-masked]>
Date: Wed, 3 Feb 2010 13:53:59 -0500

Hello David,

Comments inline...I shorten the thread a bit.

> several iterations between those two that may be required.)

I think we are in agreement here that this might be the crux of the issue.
Survey, comparison, and other types of documents IMO have mixed results in
the IETF.

Some history on 'survey/evaluation' type documents that I followed:

I remember the MIDCOM WG produced a lengthy 'strictly' technical evaluation
of many candidates and the selected protocol was never really implemented by
multiple vendors. 

http://tools.ietf.org/html/rfc4097

I remember IPfix WG went down the same road but at some point changed gears
and decided for most implemented and mature protocol. Multiple vendors today
implement IPFix.

http://tools.ietf.org/html/rfc3955

There might be others.

-Reinaldo

---

From: Song Haibin <[email-masked]>
Date: Wed, 10 Feb 2010 10:52:31 +0800

Hi Reinaldo,

> [mailto:[email-masked]] On Behalf Of Reinaldo Penno
> Sent: Thursday, February 04, 2010 2:54 AM
> To: David A. Bryan
> Cc: [email-masked]
> Subject: Re: [decade] Updated DECADE Charter (Revised)
> 
> Hello David,
> 
> Survey, comparison, and other types of documents IMO have 
> mixed results in the IETF.
> 
> I remember the MIDCOM WG produced a lengthy 'strictly' 
> technical evaluation of many candidates and the selected 
> protocol was never really implemented by multiple vendors. 
> 
> I remember IPfix WG went down the same road but at some point 
> changed gears and decided for most implemented and mature 
> protocol. Multiple vendors today implement IPFix.
> 

Thanks for your information. That is actually why we would like to choose a
small number of widely implemented underlying protocols. And we describe
that in the charter "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."

>Therefore I would suggest some wording around a pre-selection.

Yes, we would like to narrow down the candidate underlying protocols. We
could consider HTTP, WebDAV and NFS first,  and if we have other underlying
protocol as a consensus in the mailing list or at the meeting, we should
incoporate it. In the charter, we said "NFS and WebDAV (might loose http
here) are initial targets and others may be incorporated with WG consensus."

BR,
Haibin

> >> Is it possible to have a step between these two where we 
> narrow down 
> >> the candidate protocols for the survey? It might be 
> implied but the 
> >> wording leaves the door open for a number of different protocols.
> >> 
> >> volunteers, etc for each protocol. Then the pre-selection is done 
> >> naturally, if there is no interest in a certain protocol, 
> then nobody 
> >> will pick up the work.
> >> 
> >> Thanks,
> >> 
> >> Reinaldo
> >> 
> >> 
> >>> - A requirements document. This document lists the 
> requirements for 
> >>> the

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 22 Feb 2010 23:35:18 +0000

Hi Richard,
A minor comment (I am still thinking about the rest of the proposed 
Charter):

Richard Alimi wrote:

>  Submission if no active working group exists.
>
I think the part "or create an Individual Submission if no active 
working group exists". As the sponsoring Area Director I would rather 
see such work be a product of this WG, as this makes judging consensus 
easier for me.

So I would suggest rephrasing to read something like this:

  If the existing underlying protocol does not support certain
  resource management operations, DECADE may seek to define such extensions
  and present them to the respective IETF working groups, if such working group exist.

>This group may also create a

---

From: Richard Alimi <[email-masked]>
Date: Mon, 22 Feb 2010 18:46:56 -0500

Hi Alexey,

Thanks for reading through.

On Monday 22 February 2010 6:35:18 pm Alexey Melnikov wrote:
> [...snip...]

This makes sense and I've made the change locally.  We can post a new draft 
within the next day or so incorporating additional changes (if there are any).

Thanks!