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

["Y. Richard Yang" <[e-mail]>]

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:
> Hi Ove,
>
>
>    
>> -----Original Message-----
>> From: Strandberg, Ove (NSN - FI/Espoo)
>> [mailto:[e-mail]]
>> Sent: Friday, March 12, 2010 4:40 PM
>> To: ext Song Haibin; Börje Ohlman; [e-mail]
>> Subject: RE: [decade] draft-ohlman-decade-add-use-cases-reqs-00
>>
>> Hi Haibin,
>>
>> Thanks for your comments, see inline.
>>
>> Br,
>>
>> +Ove
>>
>>      
>>> -----Original Message-----
>>> From: [e-mail] [mailto:[e-mail]] On
>>> Behalf Of ext Song Haibin
>>> Sent: 09 March, 2010 08:58
>>> To: 'Börje Ohlman'; [e-mail]
>>> 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
>>>
>>>    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.
>>>        
>> 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
>
>
>    
>>> 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 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
>>>
>>>    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?
>>>        
>> 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
>>>
>>>
>>>        
>>>> -----Original Message-----
>>>> From: [e-mail]
>>>> [mailto:[e-mail]] On Behalf Of B?rje Ohlman
>>>> Sent: Monday, March 01, 2010 11:39 PM
>>>> To: [e-mail]
>>>> Subject: [decade] draft-ohlman-decade-add-use-cases-reqs-00
>>>>
>>>> Please find our new draft in the IETF drafts depository:
>>>> https://datatracker.ietf.org/doc/draft-ohlman-decade-add-use-c
>>>> ases-reqs/
>>>>
>>>> Best regards,
>>>> 	Börje Ohlman. et al
>>>>
>>>> -----Original Message-----
>>>> From: IETF I-D Submission Tool [mailto:[e-mail]]
>>>> Sent: den 1 mars 2010 16:26
>>>> To: Börje Ohlman
>>>> Cc: [e-mail]; [e-mail]; [e-mail];
>>>> [e-mail]
>>>> 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.
>>>>
>>>>
>>>> _______________________________________________
>>>> decade mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/decade
>>>>
>>>>          
>>>
>>> _______________________________________________
>>> decade mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/decade
>>>
>>>        
>>      
>
> _______________________________________________
> decade mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/decade
>