Subject: [decade] draft-ohlman-decade-add-use-cases-reqs-00

From: Börje Ohlman <[email-masked]>
Date: Mon, 1 Mar 2010 16:39:01 +0100

Please find our new draft in the IETF drafts depository:
https://datatracker.ietf.org/doc/draft-ohlman-decade-add-use-cases-reqs/

Best regards,
	Börje Ohlman. et al 

-----Original Message-----
From: IETF I-D Submission Tool [mailto:[email-masked]] 
Sent: den 1 mars 2010 16:26
To: Börje Ohlman
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: New Version Notification for draft-ohlman-decade-add-use-cases-reqs-00 

A new version of I-D, draft-ohlman-decade-add-use-cases-reqs-00.txt has been successfuly submitted by Borje Ohlman and posted to the IETF repository.

Filename:	 draft-ohlman-decade-add-use-cases-reqs
Revision:	 00
Title:		 Requirements for accessing data in network storage
Creation_date:	 2010-03-01
WG ID:		 Independent Submission
Number_of_pages: 8

Abstract:
So far, the intended scope of the DECoupled Application Data Enroute
(DECADE) working group has mainly been focused on peer-to-peer (P2P) applications.  There are however many non-P2P-based application that could also benefit from in-network storage.  The target of DECADE should thus specify a protocol that is also suitable for generic applications with certain characteristics and not only P2P applications.  This document enumerates a number of requirements that should be considered during the design and implementation of this protocol.

The IETF Secretariat.

---

From: Song Haibin <[email-masked]>
Date: Tue, 09 Mar 2010 14:58:05 +0800

Hi, 

I like this draft and think it is very interesting to discuss those
requirements in the list. I list all the three requirements below and also
with my comments in line. 

2.1.1.  Requirement

   The specification of DECADE SHOULD strive to make the DECADE in-
   network storage application-agnostic.  As a verification of this
   effort DECADE SHOULD be specified in such a way that it can address
   at least one other application type, besides P2P applications.

At this stage we say DECADE is P2P-application-agnostic. The motivation of
DECADE is from P2P applications and P2P Cache. But it can be used by other
applications with similar requirements (resource control to content
requesters with data transfer from in-network storage, read/write ... ).
Although I don't think including other applications will influence the
architecture, but for the first step, it will introduce extra complexity. I
guess when the basic requirements are solved (if the WG is charterd to do
that), it is open to the extension disucssion in DECADE.

2.2.1.  Requirement

   When certain content is popular and used by many users, the network
   part of DECADE SHOULD be able to store only one (or any limited
   number) copy of that data.  The same data can then be used to serve
   requests from multiple DECADE users.

I think we can take this as an optimization to the storage server. But it is
not easy to dertermine the number of data copies.

3.1.1.  Requirement

   DECADE SHOULD have the ability to support mobility of terminals/
   users/applications by allowing the use of a data object that is
   available near a new location when moving.  DECADE COULD also provide
   nomadic network storage.

 I'm not sure who will be responsible for the place where the contents
should be located. Is it the end user or the network storage service
provider. If it is the network storage service provider, then when and where
should the data be moved?

Xie Xie,
Haibin

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of B?rje Ohlman
> Sent: Monday, March 01, 2010 11:39 PM
> To: [email-masked]
> Subject: [decade] draft-ohlman-decade-add-use-cases-reqs-00
> 
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Subject: New Version Notification for 
> draft-ohlman-decade-add-use-cases-reqs-00 
> 
> 
> A new version of I-D, 
> draft-ohlman-decade-add-use-cases-reqs-00.txt has been 
> successfuly submitted by Borje Ohlman and posted to the IETF 
> repository.
> 
> (DECADE) working group has mainly been focused on 
> peer-to-peer (P2P) applications.  There are however many 
> non-P2P-based application that could also benefit from 
> in-network storage.  The target of DECADE should thus specify 
> a protocol that is also suitable for generic applications 
> with certain characteristics and not only P2P applications.  
> This document enumerates a number of requirements that should 
> be considered during the design and implementation of this protocol.
>                                                               
>                     
> 
> 
> The IETF Secretariat.
> 
> 
> _______________________________________________
> decade mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/decade
>

---

From: "Strandberg, Ove (NSN - FI/Espoo)" <[email-masked]>
Date: Fri, 12 Mar 2010 10:39:36 +0200

Hi Haibin,

Thanks for your comments, see inline.

Br,

+Ove 

>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of ext Song Haibin
>Sent: 09 March, 2010 08:58
>To: 'Börje Ohlman'; [email-masked]
>Subject: Re: [decade] draft-ohlman-decade-add-use-cases-reqs-00
>
>Hi, 
>
>I like this draft and think it is very interesting to discuss 
>those requirements in the list. I list all the three 
>requirements below and also with my comments in line. 
>
>2.1.1.  Requirement
>
>At this stage we say DECADE is P2P-application-agnostic. The 
>motivation of DECADE is from P2P applications and P2P Cache. 
>But it can be used by other applications with similar 
>requirements (resource control to content requesters with data 
>transfer from in-network storage, read/write ... ).
>Although I don't think including other applications will 
>influence the architecture, but for the first step, it will 
>introduce extra complexity. I guess when the basic 
>requirements are solved (if the WG is charterd to do that), it 
>is open to the extension disucssion in DECADE.

I also hope that the influence of the architecture will be minimal, however previous experience show that it is wise to include already in the beginning elementary other requirements to make sure the DECADE results will be useful for other applications also. It should be clear that IETF has long experience of challenging add ons, just mentioning MIP as one example, there are several others. This draft just tries to list one additional application that is not P2P based, this application needs to represent many other applications. The selected application needs to work as a reality check on DECADE for how well the solution can work in a larger sense. A suggestion to look at other applications at a later stage usually means that DECADE can not rework obstacles, only extend on previous work. The suggestion is to have the WG be forward thinking already such that DECADE work can have an larger area of deployment. Further there are already applications out there that combine P2P with other mechanisms, we should not limit the use of DECADE to only P2P. Thus it would be good to include some other reference application already now.
>I think we can take this as an optimization to the storage 
>server. But it is not easy to determine the number of data copies.

Agree, it would be good if we can provide the tools eventually for efficient data references etc.. Target would be to let several end users work on data independently (perhaps even with own notion (name) of data) while on data reference level the DECADE can support data reuse goals. Thinking here is that this systematic approach perhaps necessary while independent server (storage) can not on its own well recognize data reuse situation.

> I'm not sure who will be responsible for the place where the 
>contents should be located. Is it the end user or the network 
>storage service provider. If it is the network storage service 
>provider, then when and where should the data be moved?

The target would be that the mechanism for moving (copying) the data is specified, while actor for moving (coping) the data depends on the deployment. I agree this does not look to be straightforward, probably both use cases needs to be developed and then we need to see if they can be combined such that the mechanism can serve both deployments. Would this be an alternative way forward?

>> draft-ohlman-decade-add-use-cases-reqs-00.txt has been successfuly 
>> submitted by Borje Ohlman and posted to the IETF repository.
>> 
>> (DECADE) working group has mainly been focused on peer-to-peer (P2P) 
>> applications.  There are however many non-P2P-based application that 
>> could also benefit from in-network storage.  The target of DECADE 
>> should thus specify a protocol that is also suitable for generic 
>> applications with certain characteristics and not only P2P 
>> applications.
>> This document enumerates a number of requirements that should be 
>> considered during the design and implementation of this protocol.
>>                                                               
>>                     
>> 
>> 
>> The IETF Secretariat.
>> 
>>

---

From: Song Haibin <[email-masked]>
Date: Mon, 15 Mar 2010 15:15:10 +0800

Hi Ove,

> From: Strandberg, Ove (NSN - FI/Espoo) 
> [mailto:[email-masked]] 
> Sent: Friday, March 12, 2010 4:40 PM
> To: ext Song Haibin; Börje Ohlman; [email-masked]
> Subject: RE: [decade] draft-ohlman-decade-add-use-cases-reqs-00
> 
> Hi Haibin,
> 
> >From: [email-masked] [mailto:[email-masked]] On 
> >Behalf Of ext Song Haibin
> >requirements in the list. I list all the three requirements 
> below and 
> >also with my comments in line.
> >
> >2.1.1.  Requirement
> >
> motivation 
> >of DECADE is from P2P applications and P2P Cache.
> >But it can be used by other applications with similar requirements 
> >(resource control to content requesters with data transfer from 
> >in-network storage, read/write ... ).
> influence the 
> >architecture, but for the first step, it will introduce extra 
> >complexity. I guess when the basic requirements are solved 
> (if the WG 
> >is charterd to do that), it is open to the extension disucssion in 
> >DECADE.
> 
> I also hope that the influence of the architecture will be 
> minimal, however previous experience show that it is wise to 
> include already in the beginning elementary other 
> requirements to make sure the DECADE results will be useful 
> for other applications also. It should be clear that IETF has 
> long experience of challenging add ons, just mentioning MIP 
> as one example, there are several others. This draft just 
> tries to list one additional application that is not P2P 
> based, this application needs to represent many other 
> applications. The selected application needs to work as a 
> reality check on DECADE for how well the solution can work in 
> a larger sense. A suggestion to look at other applications at 
> a later stage usually means that DECADE can not rework 
> obstacles, only extend on previous work. The suggestion is to 
> have the WG be forward thinking already such that DECADE work 
> can have an larger area of deployment. Further there are 
> already applications out there that combine P2P with other 
> mechanisms, we should not limit the use of DECADE to only 
> P2P. Thus it would be good to include some other reference 
> application already now.

The scope of an IETF work should be clear and narrow enough, so that people
can concentrate on solving the real problem. However, I personally would
agree with you if the added application does not introduce much complexity.
If people are interested in contributing to the work, that will be
encouraging. 

Thanks,
Haibin

> server. But 
> >it is not easy to determine the number of data copies.
> 
> Agree, it would be good if we can provide the tools 
> eventually for efficient data references etc.. Target would 
> be to let several end users work on data independently 
> (perhaps even with own notion (name) of data) while on data 
> reference level the DECADE can support data reuse goals. 
> Thinking here is that this systematic approach perhaps 
> necessary while independent server (storage) can not on its 
> own well recognize data reuse situation.
> 
> >
> >
> >3.1.1.  Requirement
> >
> >provider. If it is the network storage service provider, 
> then when and 
> >where should the data be moved?
> 
> The target would be that the mechanism for moving (copying) 
> the data is specified, while actor for moving (coping) the 
> data depends on the deployment. I agree this does not look to 
> be straightforward, probably both use cases needs to be 
> developed and then we need to see if they can be combined 
> such that the mechanism can serve both deployments. Would 
> this be an alternative way forward?
> 
> >
> >Xie Xie,
> >Haibin
> > 
> >
> peer-to-peer (P2P)

---

From: "Y. Richard Yang" <[email-masked]>
Date: Thu, 25 Mar 2010 17:02:57 -0400

Dear Ove,

I just read 
http://tools.ietf.org/html/draft-ohlman-decade-add-use-cases-reqs-00. It 
is a good, forward-looking document. I feel that it is fair to ask 
DECADE to support one additional application beyond (chosen) P2P 
applications.

Thinking about your data-reuse requirement, I feel that it is an 
important but non-trivial requirement. Avoiding duplicate transmissions 
between DECADE servers can address the middle-mile problem (see slide 10 
of the Akamai presentation: 
http://zoo.cs.yale.edu/classes/cs435/cs435-spring-2010/readings/Akamai_2009_analystday_presentation.pdf). 
On the other hand, should this be addressed be DECADE or another 
protocol/mechanism?

Consider a concrete example, where both clients A1 and A2 intend to 
upload the same content block B to a Decade server S.

A1 --------> Decade server S <----------- A2

If both A1 and A2 upload to S, the system uses network resources twice. 
There are several ways to remove the duplication: Consider the following 
two options:

[O1] A1 uploads content block B to S; When A2 uploads, DECADE allows A2 
to detect that block B is already at S and avoid transfer. The detection 
can depend on naming, and hashing (with bloom filtering).

[O2] If the paths from A1 to S and A2 to S share common links that use 
WAN compression, then the WAN compression can remove the duplication on 
those links without the need of DECADE support.

I feel that [O1] is more general but add complexity to DECADE. One sure 
can extend the reuse-case analysis to more complex settings of reuse 
across DECADE servers.

It clearly is an item that should be discussed at the WG.

Cheers,

Richard

On 3/15/2010 3:15 AM, Song Haibin wrote:
>>>    effort DECADE SHOULD be specified in such a way that it
>>>        
>> can address
>>      
>>>    When certain content is popular and used by many users,
>>>        
>> the network
>>      
>>>    number) copy of that data.  The same data can then be
>>>        
>> used to serve
>>      
>>>    available near a new location when moving.  DECADE COULD
>>>        
>> also provide
>>      
>>>    nomadic network storage.
>>>
>>> I'm not sure who will be responsible for the place where
>>>        
>> the contents
>>      
>>>> So far, the intended scope of the DECoupled Application
>>>>          
>> Data Enroute
>>      
>>>> applications.  There are however many non-P2P-based
>>>>          
>> application that
>>