Re: [decade] Mobility req

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

Hmm Rich,

I am uncertain of specifics here, just talkiung about requirements makes it hard to be too specific. But with switchover I simply mean the situation that at one point you are engaged as client in accessing data on the far away storage/cache, the next moment it would be possible to access a local storage/cache instead. For me as client it should not take too long to for me to start using the local storage/cache, thus there should not be too long delay between working on far away storage/cache to start working on local storage/cache.

This is quite straitforward explanaition and the most elementary version of mobility. In case someone has more stricter wiew on mobility, you need to speak up.

Br,

+Ove

>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] 
>On Behalf Of ext Richard Alimi
>Sent: 11 June, 2010 08:35
>To: Strandberg, Ove (NSN - FI/Espoo)
>Cc: ext David A. Bryan; [e-mail]
>Subject: Re: [decade] Mobility req
>
>Hi Ove,
>
>On Fri, Jun 11, 2010 at 1:22 AM, Strandberg, Ove (NSN - 
>FI/Espoo) <[e-mail]> wrote:
>> Hi Rich,
>>
>> Looking at the message you refer to, I can see that we agree 
>on the basis for the mob req.
>
>If it is as simple as being able to discover multiple servers, 
>then I think that can be useful and will not add complexity to 
>the protocol.
>Of course, this does *not* mean that a DECADE client must have 
>access to multiple servers.  I would envision that to depend 
>on the particular deployment.
>
>> We probably will be able to cope with the use of some of the 
>basic requirements for mob req too.
>>
>> There are however one additional characteristic that comes 
>with mobility; the switch over to use a local storage/cache 
>needs to work fast enough for a mobile client. I am not going 
>to specify numbers, but let's say the client is working 
>against a far away storage/cache. For the client to think that 
>a local storage/access is better, then the switchover should 
>not produce delay of several seconds (guessimate, not hard 
>number, just illustrate the point). If the switchover has too 
>long delay, then it would probably be better to continue 
>working against the far away storage/cache.
>
>I'm unclear as to what you mean by "switchover" - can you 
>provide some more specifics?  What type of application are you 
>envisioning, and what specific operations do you intend to 
>include in the "switchover"
>process?
>
>Rich
>
>>
>> Br,
>>
>> +Ove
>>
>>>-----Original Message-----
>>>From: [e-mail] [mailto:[e-mail]] On 
>>>Behalf Of ext Richard Alimi
>>>Sent: 10 June, 2010 16:54
>>>To: Strandberg, Ove (NSN - FI/Espoo)
>>>Cc: ext David A. Bryan; [e-mail]
>>>Subject: Re: [decade] Mobility req
>>>
>>>Hi Ove,
>>>
>>>On Thu, Jun 10, 2010 at 4:32 AM, Strandberg, Ove (NSN -
>>>FI/Espoo) <[e-mail]> wrote:
>>>> 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.
>>>
>>>If there are multiple storage locations available to a 
>client, I think 
>>>it is reasonable to let the client choose which to use.  See 
>my reply 
>>>to Börje Ohlman from the previous charter
>>>discussion:
>>>  http://www.ietf.org/mail-archive/web/decade/current/msg00149.html
>>>
>>>However, note that we must not overlap with ALTO.  Note the explicit 
>>>out-of-scope item in the DECADE charter:
>>>  Locating the "best" in-network storage location from which to 
>>>retrieve
>>>  content if there are more than one location can provide the same
>>>  content.
>>>
>>>>
>>>> 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?
>>>
>>>I think this is fine.
>>>
>>>Rich
>>>
>>>>
>>>> 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
>>>>>>
>>>>>>
>>>>>
>>>> _______________________________________________
>>>> decade mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/decade
>>>>
>>>
>>
>