Subject: [decade] scope discussion

From: Song Haibin <[email-masked]>
Date: Fri, 11 Dec 2009 11:21:43 +0800

Dear all,
 
While many people in the meeting room at IETF 76 thought the problem was
clear, and reasonable to solve, but not well-scoped (mainly about the
in-network storage access protocol). I propose a few options for the
protocol scope.
 
(1) A standard IAP protocol, which includes read/write & resource control.
P2P client can use this protocol to upload contents to/download contents
from the in-network storage, or send commands to its in-network storage on
resource sharing policies with remote peers (bandwidth, connections, etc. );
 
(2) A single standard read/write protocol.  P2P client can use this protocol
to upload contents to/download contents from the in-network storage.
 
(3) A resource control and transport negotiation protocol. We don't need to
standardize the read/write protocol here, but P2P client can use this
protocol to negotiate the necessary transport protocol for the content, and
send commands to its in-network storage on resource sharing policies with
remote peers (bandwidth, connections, etc. );
 
For option (1) and (2), I think it might be a little harder to enable a
single read/write protocol qualified to transport various kinds of contents,
and there might be a little overlap with NFS/WebDAV. 
 
How about limiting the IAP scope to option (3)? I think it is much cleaner
and feasible to solve.
 
BR,
Haibin

---

From: Yong Lucy <[email-masked]>
Date: Mon, 14 Dec 2009 14:25:37 -0600

I studied NFS WG work a bit. NFS works on remote direct memory access (RDMA)
protocol that allows remote memory access operation. The protocol works in
RPC based architecture. IAP protocol includes read/write protocol for
in-network storage access. IAP may be able to use RDAM for read/write
operation. The question is that if DECADE architecture has to use
client/server architecture.  

IAP also needs the protocol to pass the in-network storage access reference
and authority to other peers or in-network storage itself so that the peers
or the storage can use the references to perform the read/write actions over
in-network storage. I don't see this work under NFS WG scope. 

Not sure if DECADE work should include the protocol to help the negotiation
of transport protocol underline. 

Would like to see some experts on NFS to provide the input.

Regards,

Lucy 

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Song Haibin
Sent: Thursday, December 10, 2009 9:22 PM
To: [email-masked]
Subject: [decade] scope discussion

Dear all,

BR,

Haibin

---

From: Song Haibin <[email-masked]>
Date: Thu, 17 Dec 2009 10:41:13 +0800

Hi Lucy,

Thanks for your reply. Sorry for the late reply because I'm very busy these
days. Please see inline.

> -----Original Message-----
> From: Yong Lucy [mailto:[email-masked]] 
> Sent: Tuesday, December 15, 2009 4:26 AM
> To: 'Song Haibin'; [email-masked]
> Subject: RE: [decade] scope discussion
> 
> I studied NFS WG work a bit. NFS works on remote direct 
> memory access (RDMA) protocol that allows remote memory 
> access operation. The protocol works in RPC based 
> architecture. IAP protocol includes read/write protocol for 
> in-network storage access. IAP may be able to use RDAM for 
> read/write operation. 

I am sorry that I know little about RDMA, maybe some experts on NFS could
provide good comments here. IMHO, there are many kinds of contents could be
transferred between client and in-network storage. For real-time or
near-real-time media, RTP/RTCP might be used for the transport. For
non-real-time data, you might use HTTP or other standard protocol (might be
RDMA?) for the transport. That's why I suggest IAP should not include the
read/write protocol itself but instead the negotiation of transport protocol
underline. However, comments from NFS experts would be very appreciated.

>The question is that if DECADE 
> architecture has to use client/server architecture.  
> 

IMO, yes. What's in your mind?
  
> 
> IAP also needs the protocol to pass the in-network storage 
> access reference and authority to other peers or in-network 
> storage itself so that the peers or the storage can use the 
> references to perform the read/write actions over in-network 
> storage. I don't see this work under NFS WG scope. 
> 
This is related to access control and resource control. P2P applications
clients usually have the resource control and access control locally, but
now they have their contents in the network core, so they need to have the
ability ( with IAP) to control the resource allocation and sharing policies
for their contents in the in-network storage.   I don't think this is under
NFS scope. Any comments?

> 
> Not sure if DECADE work should include the protocol to help 
> the negotiation of transport protocol underline. 
> 

See above.  

> Would like to see some experts on NFS to provide the input.
Me too.

BR,
Haibin

> 
> Regards,
> 
> Lucy 
> 
>  
> 
>  
> 
>  
> 
> ________________________________
> 
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Song Haibin
> While many people in the meeting room at IETF 76 thought the 
> problem was clear, and reasonable to solve, but not 
> well-scoped (mainly about the in-network storage access 
> protocol). I propose a few options for the protocol scope.
> 
>  
> 
> (1) A standard IAP protocol, which includes read/write & 
> resource control. P2P client can use this protocol to upload 
> contents to/download contents from the in-network storage, or 
> send commands to its in-network storage on resource sharing 
> policies with remote peers (bandwidth, connections, etc. );
> 
>  
> 
> (2) A single standard read/write protocol.  P2P client can 
> use this protocol to upload contents to/download contents 
> from the in-network storage.
> 
>  
> 
> (3) A resource control and transport negotiation protocol. We 
> don't need to standardize the read/write protocol here, but 
> P2P client can use this protocol to negotiate the necessary 
> transport protocol for the content, and send commands to its 
> in-network storage on resource sharing policies with remote 
> peers (bandwidth, connections, etc. );
> 
>  
> 
> For option (1) and (2), I think it might be a little harder 
> to enable a single read/write protocol qualified to transport 
> various kinds of contents, and there might be a little 
> overlap with NFS/WebDAV. 
> 
>  
> 
> How about limiting the IAP scope to option (3)? I think it is 
> much cleaner and feasible to solve.
> 
>  
> 
> BR,
> 
> Haibin
> 
>

---

From: Lars Eggert <[email-masked]>
Date: Thu, 17 Dec 2009 08:41:01 +0200

Hi,

> Would like to see some experts on NFS to provide the input.

in that case, let me suggest that you ask them by putting together an email and sending it to [email-masked]?

Lars

---

From: Spencer Shepler <[email-masked]>
Date: Thu, 17 Dec 2009 08:19:59 -0600

I can help. I have been lurking but apologize that I haven't been  
following closely enough to know the specific question(s).

Spencer

On Dec 17, 2009, at 12:41 AM, Lars Eggert <[email-masked]> wrote:

> in that case, let me suggest that you ask them by putting together  
> an email and sending it to [email-masked]?
>
> Lars
> _______________________________________________
> decade mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/decade

---

From: Reinaldo Penno <[email-masked]>
Date: Thu, 17 Dec 2009 14:16:05 -0500

I'm not an expert on NFS by any means (know some WebDAV) but I would like to
discuss the feasibility of these protocols and any other from a different
point of view. A few points.

* Since this protocol will be hopefully implemented by many different P2P
clients that run on top of many different OSes, I would venture to say that
the chances that any application layer protocol will be embraced has do
with:

  1 - Reusability: If it manages to reuse software already present in the
clients it gets bonus points. For example, many P2P clients already have
HTTP in it.
   1.1 - Some smart phones such as iPhone SDK also have well-defined HTTP
APIs.
  2 - Socket API: Capability of relying only on the well-defined simple
socket APIs instead of expecting say, NFS, to be in the kernel. I know that
you could implement NFS in user space, but that goes to point 3 below
  3 - Avoiding Code bloating: Many of these P2P clients have a really low
footprint requirement even when installed on PCs and would have even more
strict requirements when present on Smart Phones.

Thanks,

Reinaldo

---

From: "Xiao, Lin (NSN - CN/Beijing)" <[email-masked]>
Date: Fri, 18 Dec 2009 14:03:57 +0800

Hi Haibin,
 
I think I agree with your opinion. Option (1) and (2) are contents
relevant.Most of the application themselves have their own ways to do
the read/write thing. In order to make the Decade independent with the
applications, we just need design a simple protocol to do the resource
store and access control. That is to help setting up the contact between
the peer and the in-network storage, maybe with the negotiation
information about which protocol will be used for read/write the data.

Br
Xiao, Lin 

From: [email-masked] [mailto:[email-masked]] On Behalf
Of ext Song Haibin
Sent: Friday, December 11, 2009 11:22 AM
To: [email-masked]
Subject: [decade] scope discussion

Dear all,

(1) A standard IAP protocol, which includes read/write & resource
control. P2P client can use this protocol to upload contents to/download
contents from the in-network storage, or send commands to its in-network
storage on resource sharing policies with remote peers (bandwidth,
connections, etc. );
 
(2) A single standard read/write protocol.  P2P client can use this
protocol to upload contents to/download contents from the in-network
storage.
 
(3) A resource control and transport negotiation protocol. We don't need
to standardize the read/write protocol here, but P2P client can use this
protocol to negotiate the necessary transport protocol for the content,
and send commands to its in-network storage on resource sharing policies
with remote peers (bandwidth, connections, etc. );
 
For option (1) and (2), I think it might be a little harder to enable a
single read/write protocol qualified to transport various kinds of
contents, and there might be a little overlap with NFS/WebDAV. 
 
How about limiting the IAP scope to option (3)? I think it is much
cleaner and feasible to solve.
 
BR,
Haibin

---

From: Song Haibin <[email-masked]>
Date: Fri, 18 Dec 2009 14:59:49 +0800

Hi Spencer,

Very glad to hear from you. And thank Lars for the suggestion, so I also
copied this email to [email-masked]. I would like to copy it to WebDAV
mailing list too, but I do not know the address : (

I think I should introduce some background. Please refer to this wiki page
for the initial charter proposal for DECADE BOF at IETF 76.
http://trac.tools.ietf.org/bof/trac/wiki/decade 

The feedback from the BOF is that there might be some overlap between the
IAP protocol and NFS/WebDAV. So I sent an email to do scope discussion.
Please refer to
http://www.ietf.org/mail-archive/web/decade/current/msg00106.html  and
replied by Lucy,
http://www.ietf.org/mail-archive/web/decade/current/msg00107.html, Reinaldo
http://www.ietf.org/mail-archive/web/decade/current/msg00111.html and Xiao
Lin http://www.ietf.org/mail-archive/web/decade/current/msg00112.html.

So we want to continue the discussion, and let NFS & WebDAV experts to
comment on list to see if there is any overlap, and to see if the new
proposed IAP scope is reasonable and can avoid this kind of  overlap.

Xie Xie,
Haibin

> [mailto:[email-masked] <mailto:[email-masked]> ] On
Behalf Of Spencer Shepler
> Sent: Thursday, December 17, 2009 10:20 PM
> To: Lars Eggert
> Cc: [email-masked]
> Subject: Re: [decade] scope discussion
>
>
> I can help. I have been lurking but apologize that I haven't
> been following closely enough to know the specific question(s).
>
> Spencer
>
>
>
> > in that case, let me suggest that you ask them by putting
> together an
> > email and sending it to [email-masked]?
> >
> > Lars
<https://www.ietf.org/mailman/listinfo/decade> 
<https://www.ietf.org/mailman/listinfo/decade>

---

From: Song Haibin <[email-masked]>
Date: Fri, 18 Dec 2009 15:10:22 +0800

Hi Spencer,

I just missed DECADE BOF meeting minutes at IETF 76. I don't know if you
need it to have a better understanding of the background. The link is
announced by Rich Woundy two weeks ago and you can find it below. 
http://www.ietf.org/proceedings/09nov/minutes/decade.txt

Thank you very much.

Haibin

> Sent: Friday, December 18, 2009 3:00 PM
> To: 'Spencer Shepler'; 'Lars Eggert'
> Cc: [email-masked]; [email-masked]
> Very glad to hear from you. And thank Lars for the 
> suggestion, so I also copied this email to [email-masked]. I 
> would like to copy it to WebDAV mailing list too, but I do 
> not know the address : (
> 
> I think I should introduce some background. Please refer to 
> this wiki page for the initial charter proposal for DECADE 
> BOF at IETF 76.
> The feedback from the BOF is that there might be some overlap 
> between the IAP protocol and NFS/WebDAV. So I sent an email 
> to do scope discussion.
> Please refer to
> http://www.ietf.org/mail-archive/web/decade/current/msg00106.h
> tml  and replied by Lucy, 
> http://www.ietf.org/mail-archive/web/decade/current/msg00111.h
> tml and Xiao Lin 
> http://www.ietf.org/mail-archive/web/decade/current/msg00112.html.
> 
> So we want to continue the discussion, and let NFS & WebDAV 
> experts to comment on list to see if there is any overlap, 
> and to see if the new proposed IAP scope is reasonable and 
> can avoid this kind of  overlap.
> 
> 
> Xie Xie,
> Haibin
> 
>

---

From: "Woundy, Richard" <[email-masked]>
Date: Fri, 18 Dec 2009 16:39:54 -0500

One other potentially useful document is the most recent "DECADE
Requirements" draft, just updated this week:

<http://www.ietf.org/id/draft-gu-decade-reqs-02.txt>

This draft still assumes the original scope of the DECADE effort, but it
would still be useful to compare these requirements against the
capabilities of existing protocols, particularly NFS.

-- Rich

P.S. All of the DECADE BOF proceedings can be found here:
<https://datatracker.ietf.org/meeting/76/materials.html#wg-decade>.

-----Original Message-----
Of Song Haibin
Sent: Friday, December 18, 2009 2:10 AM

Hi Spencer,

Thank you very much.

Haibin

---

From: Song Haibin <[email-masked]>
Date: Mon, 21 Dec 2009 16:21:20 +0800

Hi Reinaldo,

These are very good general requirements to the protocol design. I think
HTTP could be a good candiate protocol for the signaling between P2P client
and in-network storage to do resource control and some negotiation. We
should not tie closely to a specific complicated file system, which will
make the scalability a big problem.

Haibin

> From: Reinaldo Penno [mailto:[email-masked]] 
> Sent: Friday, December 18, 2009 3:16 AM
> To: Song Haibin; 'Yong Lucy'; [email-masked]
> I'm not an expert on NFS by any means (know some WebDAV) but 
> I would like to discuss the feasibility of these protocols 
> and any other from a different point of view. A few points.
> 
> * Since this protocol will be hopefully implemented by many 
> different P2P clients that run on top of many different OSes, 
> I would venture to say that the chances that any application 
> layer protocol will be embraced has do
> with:
> 
>   1 - Reusability: If it manages to reuse software already 
> present in the clients it gets bonus points. For example, 
> many P2P clients already have HTTP in it.
>    1.1 - Some smart phones such as iPhone SDK also have 
> well-defined HTTP APIs.
>   2 - Socket API: Capability of relying only on the 
> well-defined simple socket APIs instead of expecting say, 
> NFS, to be in the kernel. I know that you could implement NFS 
> in user space, but that goes to point 3 below
>   3 - Avoiding Code bloating: Many of these P2P clients have 
> a really low footprint requirement even when installed on PCs 
> and would have even more strict requirements when present on 
> Smart Phones.
> 
> Thanks,
> 
> Reinaldo
> 
> 
> > Thanks for your reply. Sorry for the late reply because I'm 
> very busy 
> > these days. Please see inline.
> > 
> memory access 
> >> (RDMA) protocol that allows remote memory access operation. The 
> >> protocol works in RPC based architecture. IAP protocol includes 
> >> read/write protocol for in-network storage access. IAP may 
> be able to 
> >> use RDAM for read/write operation.
> > 
> > I am sorry that I know little about RDMA, maybe some experts on NFS 
> > could provide good comments here. IMHO, there are many kinds of 
> > contents could be transferred between client and in-network 
> storage. 
> > For real-time or near-real-time media, RTP/RTCP might be 
> used for the 
> > transport. For non-real-time data, you might use HTTP or other 
> > standard protocol (might be
> > RDMA?) for the transport. That's why I suggest IAP should 
> not include 
> > the read/write protocol itself but instead the negotiation of 
> > transport protocol underline. However, comments from NFS 
> experts would be very appreciated.
> > 
> >> IAP also needs the protocol to pass the in-network storage access 
> >> reference and authority to other peers or in-network 
> storage itself 
> >> so that the peers or the storage can use the references to perform 
> >> the read/write actions over in-network storage. I don't 
> see this work 
> >> under NFS WG scope.
> >> 
> > This is related to access control and resource control. P2P 
> > applications clients usually have the resource control and access 
> > control locally, but now they have their contents in the 
> network core, 
> > so they need to have the ability ( with IAP) to control the 
> resource allocation and sharing policies
> >> Not sure if DECADE work should include the protocol to help the 
> >> negotiation of transport protocol underline.
> >> 
> > 
> > See above.  
> > 
> >> 
> >> While many people in the meeting room at IETF 76 thought 
> the problem 
> >> was clear, and reasonable to solve, but not well-scoped 
> (mainly about 
> >> the in-network storage access protocol). I propose a few 
> options for 
> >> the protocol scope.
> >> 
> >>  
> >> 
> >> control. P2P client can use this protocol to upload contents 
> >> to/download contents from the in-network storage, or send 
> commands to 
> >> its in-network storage on resource sharing policies with 
> remote peers 
> use this 
> >> (3) A resource control and transport negotiation protocol. 
> We don't 
> >> need to standardize the read/write protocol here, but P2P 
> client can 
> >> use this protocol to negotiate the necessary transport 
> protocol for 
> >> the content, and send commands to its in-network storage 
> on resource 
> >> sharing policies with remote peers (bandwidth, connections, etc. );
> >> 
> >>  
> >> 
> >> For option (1) and (2), I think it might be a little 
> harder to enable 
> >> a single read/write protocol qualified to transport 
> various kinds of

---

From: Yong Lucy <[email-masked]>
Date: Mon, 28 Dec 2009 16:04:31 -0600

Hi Haibin,

I agree that HTTP could be a good candidate protocol between p2p client and
in-network storage for resource control and remote storage access
negotiation. This protocol should not tight to a specific file system or
transport methods. 

>From the architecture perspective, in-network storage application
architecture requires all these pieces coherently work together. It would be
nice to have a framework document to specify the architecture and state
where to apply the signaling protocol, where to hook on transport method,
where to use storage access, and how they will work together for supporting
the application. Then we may more clear that such signaling protocol is not
addressed by either NFS or WebDAV and DECADE will just work on the signaling
protocol part in the application.

Cheers,
Lucy 

> From: Song Haibin [mailto:[email-masked]]
> Sent: Monday, December 21, 2009 2:21 AM
> To: 'Reinaldo Penno'; 'Yong Lucy'; [email-masked]

---

From: Song Haibin <[email-masked]>
Date: Wed, 30 Dec 2009 16:15:06 +0800

Hi Lucy,

> Sent: Tuesday, December 29, 2009 6:05 AM
> To: 'Song Haibin'; 'Reinaldo Penno'; [email-masked]
> I agree that HTTP could be a good candidate protocol between 
> p2p client and in-network storage for resource control and 
> remote storage access negotiation. This protocol should not 
> tight to a specific file system or transport methods. 
> 
Yes. IMO, resource control also includes access control and authorization.
But developping the transport protocol itself will be excluded.

> From the architecture perspective, in-network storage 
> application architecture requires all these pieces coherently 
> work together. It would be nice to have a framework document 
> to specify the architecture and state where to apply the 
> signaling protocol, where to hook on transport method, where 
> to use storage access, and how they will work together for 
> supporting the application. Then we may more clear that such 
> signaling protocol is not addressed by either NFS or WebDAV 
> and DECADE will just work on the signaling protocol part in 
> the application.

Good, we will update the problem statement draft to specify that. Actually
in Section 4 and section 5 of the problem statement draft, we already have
something about the architecture and usage scenarios. But we will specify
the differences of signaling protocol and transport methods in the next
revision. Thank you for the good suggestion.

BR,
Haibin

> > These are very good general requirements to the protocol design. I 
> > think HTTP could be a good candiate protocol for the 
> signaling between 
> > P2P client and in-network storage to do resource control and some 
> > negotiation. We should not tie closely to a specific 
> complicated file 
> > system, which will make the scalability a big problem.
> > 
> > Haibin
> > 
> > 
> > > I'm not an expert on NFS by any means (know some WebDAV) 
> but I would 
> > > like to discuss the feasibility of these protocols and any other 
> > > from a different point of view. A few points.
> > >
> > > different P2P clients that run on top of many different OSes, I 
> > > would venture to say that the chances that any application layer 
> > > protocol will be embraced has do
> > > with:
> > >
> > >   1 - Reusability: If it manages to reuse software 
> already present 
> > > in the clients it gets bonus points. For example, many 
> P2P clients 
> > > already have HTTP in it.
> well-defined 
> > > HTTP APIs.
> > >   2 - Socket API: Capability of relying only on the well-defined 
> > > simple socket APIs instead of expecting say, NFS, to be in the 
> > > kernel. I know that you could implement NFS in user 
> space, but that 
> > > goes to point 3 below
> > >   3 - Avoiding Code bloating: Many of these P2P clients have a 
> > > really low footprint requirement even when installed on PCs and 
> > > would have even more strict requirements when present on Smart 
> > > Phones.
> > >
> > > Thanks,
> > >
> > > Reinaldo
> > >
> > >
> > > > I am sorry that I know little about RDMA, maybe some experts on 
> > > > NFS could provide good comments here. IMHO, there are 
> many kinds 
> > > > of contents could be transferred between client and in-network
> > > storage.
> > > >> so that the peers or the storage can use the references to 
> > > >> perform the read/write actions over in-network storage. I don't
> > > see this work
> > > >> under NFS WG scope.
> > > >>
> > > >> sharing policies with remote peers (bandwidth, 
> connections, etc. 
> > > >> );
> > > >>
> > > >>
> > > >>