Re: [decade] Mobility req

[Richard Alimi <[e-mail]>]

Hi Ove,

On Fri, Jun 11, 2010 at 2:55 AM, Strandberg, Ove (NSN - FI/Espoo)
<[e-mail]> wrote:
> 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.

If it is beginning to use a new server, that should simply be a
problem of making sure the handshake process is quick (less than a
second or two should be pretty simple to achieve).  If you also mean
that data needs to be migrated to the new storage location before it
is considered "usable", then I don't know what you can guarantee.  Of
course, a client could be smarter about migrating data on-demand.

As David was mentioning, I think this is a perfect example of where
certain requirements could quickly become complex to handle.  So, in
short, allowing a client to explicitly store/retrieve to/from multiple
servers (and possibly explicitly copying/moving data between servers)
is something that I think is reasonable to consider.  However, before
going beyond that for "mobility", we need to be specific about what is
being done.  Using David's model of "do no harm" I think is a good
approach here.

Rich

>
> 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
>>>>>
>>>>
>>>
>>
>