[decade] Mobility req

["Strandberg, Ove (NSN - FI/Espoo)" <[e-mail]>]

Hi David,

Thanks for your comments! Let's here look at the most intresting case; mobility requirement ;-)

The mobility requirement is not necessary a complex issue, but of course it depends on the viewer. If you want a complex solution you clearly can get a complex solution.

My personal issue is the sense of clients that move about, they are mobile. In case the used network storage / cache through time gets somewhat far off, then it would be beneficial for the client to be able to access a storage/cache closer. So in essence the main and most basic mobility aspect would be the efficient support for a mobile client to be able to access local caches instead of being forced to have a big backhaul to original cache. 

This now my personal motivation for mobile requirement, I hope this can be seen as an acceptable reasoning and shared with you others too. In case you agree on the potential concern, then we might look more at how to specify the requirement. Is this a good way forward?

Br,

+Ove

>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On 
>Behalf Of ext David A. Bryan
>Sent: 07 June, 2010 22:58
>To: Strandberg, Ove (NSN - FI/Espoo)
>Cc: [e-mail]
>Subject: Re: [decade] Merge requirements documents?
>
>I actually remember things a bit differently at the meeting, 
>with my general sense being that there wasn't broad support 
>for most of the new requirements. At least for now (perhaps I 
>don't understand the rational fully), I personally don't see a 
>need to include any of them, with the exception of application 
>agnostic (in the modified form below, which isn't a 
>requirement but a guiding principal).
>
>I think that the mobility requirement needed more discussion 
>-- most folks seemed to feel that it was a bit too complex for 
>now, and personally, I didn't really understand the problem 
>this would address.
>A very simplistic description of the major chartered use case 
>of DECADE is to allow a peer to make things available 
>in-network so that others can obtain it without having to use 
>the link to the peer itself. In my view, it isn't intended to 
>be generic storage for the user to place things that they want 
>to be able to access easily themselves. While having storage 
>near me topologically might reduce the cost of putting it in 
>the data locker in the first place, I don't really see how 
>mobility is very critical when the major purpose is to allow 
>me to place something in the network for someone else to obtain.
>I may just not quite understand what you are advocating -- can 
>you clarify a use case where we need this for the main P2P application?
>
>Data reuse is something that I simply see as an implementation issue.
>Obviously, a given implementation might choose to compare 
>copies of data that it is storing and to consolidate them, but 
>from a protocol/network perspective, I think we are adding 
>complexity if we track versions, number of copies stored, who 
>has shared which access rights, etc. -- so much so that it 
>seems unlikely to justify the cost.
>My preference would be that a user has access to their locker, 
>and can place things in it, provide references to it, etc., 
>but that each user's data -- at least from the perspective of 
>the protocol -- is unique and managed by them. Again, as I 
>said, that wouldn't preclude an implementation from making 
>this optimization, I just don't see requirement/protocol 
>design as the right place for it.
>
>Finally, my take on the application technique issue at the meeting was
>this: In P2PSIP, we tried a "do no harm" approach. The 
>protocol for P2PSIP (RELOAD) is essentially a DHT protocol. 
>The protocol is optimized for use in SIP 
>registration/location, and we agreed that we wouldn't add 
>unnecessary complexity that wasn't needed by that one 
>application. That said, we have tried very hard (and 
>deliberately) to make sure that so long as it didn't increase 
>complexity, that we thought about other applications and tried 
>not to design RELOAD in a way that would preclude use for 
>other applications. I'd like a similar approach here -- we 
>deliberately design for the single application of storing 
>information for P2P applications, but if others can point out 
>other applications that dictate a design decision and 
>(critically) which do not add complexity/require new features, 
>we try to make design decisions that allow that flexibility 
>when possible. I see this as quite different from adding 
>different application scenarios and requiring that the 
>protocol support all of them -- that is, in my opinion, likely 
>to make this problem too broad and increase the difficulty of 
>designing a protocol.
>
>David
>
>
>On Fri, Jun 4, 2010 at 3:14 AM, Strandberg, Ove (NSN - 
>FI/Espoo) <[e-mail]> wrote:
>> Dear Decade email list,
>>
>> There were additional requirements identified for Decade that was 
>> presented and discussed in the Anaheim IETF meeting (see minutes in 
>> http://www.ietf.org/proceedings/10mar/minutes/decade.html). We  
>> basically brought some few additional requirements to complement the 
>> already nice requirement list in draft-gu-decade-reqs-04. 
>The authors 
>> of the draft-ohlman-decade-add-use-cases-reqs-00 draft would like to 
>> suggest that the additional requirements could be incorporated into 
>> one
>>
>> requirement document, albeit into the draft-gu-decade-reqs-04 draft. 
>> The two first requirements "application agnostic" and "data reuse" 
>> seemed to be well received, while the "mobility" requirement needs 
>> further discussion. What do the authors of 
>draft-gu-decade-reqs-04 think about this merge proposal?
>>
>> We would like to also ask the DECADE email list to make comments on 
>> the suggestion to combine both drafts into one document. Is this an 
>> acceptable way forward?
>>
>> Br,
>>
>> +Ove
>>
>> [e-mail]
>>
>> _______________________________________________
>> decade mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/decade
>>
>>
>