Subject: [decade] Merge requirements documents?

From: "Strandberg, Ove (NSN - FI/Espoo)" <[email-masked]>
Date: Fri, 4 Jun 2010 10:14:11 +0300

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

[email-masked]

---

From: "David A. Bryan" <[email-masked]>
Date: Mon, 7 Jun 2010 15:57:59 -0400

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)
<[email-masked]> 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?
>
> suggestion to combine both drafts into one document. Is this an acceptable
> way forward?
>
> Br,
>
> +Ove
>
> [email-masked]
>
> _______________________________________________
> decade mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/decade
>
>

---

From: "Strandberg, Ove (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 10 Jun 2010 11:32:35 +0300

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: [email-masked] [mailto:[email-masked]] On 
>Behalf Of ext David A. Bryan
>Sent: 07 June, 2010 22:58
>To: Strandberg, Ove (NSN - FI/Espoo)
>Cc: [email-masked]
>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?
>
>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.
>
>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) <[email-masked]> wrote:
>> Dear Decade email list,
>>
>> 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 
>> 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
>>
>> [email-masked]
>>

---

From: Richard Alimi <[email-masked]>
Date: Thu, 10 Jun 2010 09:53:48 -0400

Hi Ove,

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

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…

I think this is fine.

Rich

---

From: "Strandberg, Ove (NSN - FI/Espoo)" <[email-masked]>
Date: Fri, 11 Jun 2010 08:22:50 +0300

Hi Rich,

Looking at the message you refer to, I can see that we agree on the basis for the mob req. 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.

Br,

+Ove   

>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of ext Richard Alimi
>Sent: 10 June, 2010 16:54
>Cc: ext David A. Bryan; [email-masked]
>Subject: Re: [decade] Mobility req
>
>Hi Ove,
>
>On Thu, Jun 10, 2010 at 4:32 AM, Strandberg, Ove (NSN - 
>> 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:
>However, note that we must not overlap with ALTO.  Note the 
>explicit out-of-scope item in the DECADE charter:
>> 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
>>
>>>-- 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.
>>>P2PSIP (RELOAD) is essentially a DHT protocol.
>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
>>>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
>>>
>>>
>>>> suggest that the additional requirements could be 
>incorporated into 
>>>> one
>>>>

---

From: Richard Alimi <[email-masked]>
Date: Fri, 11 Jun 2010 01:34:50 -0400

Hi Ove,

On Fri, Jun 11, 2010 at 1:22 AM, Strandberg, Ove (NSN - FI/Espoo)
<[email-masked]> 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.
>

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

---

From: "Strandberg, Ove (NSN - FI/Espoo)" <[email-masked]>
Date: Fri, 11 Jun 2010 09:55:08 +0300

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

>Sent: 11 June, 2010 08:35
>On Fri, Jun 11, 2010 at 1:22 AM, Strandberg, Ove (NSN - 
>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.
>
>> 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
>>
>>>From: [email-masked] [mailto:[email-masked]] On 
>>>Behalf Of ext Richard Alimi
>>>but of course it depends on the viewer. If you want a 
>complex solution 
>>>you clearly can get a complex solution.
>>>>
>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.
>>>
>>>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
>>>>
>copies of 
>protocol for

---

From: "Strandberg, Ove (NSN - FI/Espoo)" <[email-masked]>
Date: Fri, 11 Jun 2010 10:47:11 +0300

Hi David,

I think that one main reason for difference in opinion between us David is the basic approach and view of DECADE. You clearly think mostly about P2P application scenario. I on the other hand think that when we specify a protocol for network storage / cache (usually from an client perspective) we should make sure the same network storage / cache protocol can be used for other application scenarios too. I fully support the P2P scenario, but the effort to make the broader applicability possible, should be well worth spending. Basically it would IMHO be good for us to make the protocol more succeful. Agreed that the scope needs to be narrow enough, however if you like to look at P2P, I would be happy look after complementary scenarios ;-) However to be able to achieve this I hope that these additional requirements should be included. I am sure we will together make sure that we do not make complex recommendations in the end ;-)

Br,

+Ove

---

From: Richard Alimi <[email-masked]>
Date: Fri, 11 Jun 2010 08:47:10 -0400

Hi Ove,

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

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

---

From: Richard Alimi <[email-masked]>
Date: Fri, 11 Jun 2010 09:02:21 -0400

> ...  So, in
> is something that I think is reasonable to consider.

I'll make one other clarification here.  The reason that I think this
is reasonable to support such an approach, is because these basic
operations are likely to be needed anyways for P2P.  It does not
really require any new intelligence on behalf of the DECADE server, or
any coordination between DECADE servers.  In fact, it may not even be
necessary to add an explicit requirement for it.

Rich

---

From: Richard Alimi <[email-masked]>
Date: Fri, 11 Jun 2010 09:38:26 -0400

Hi Ove,

We need to be careful to stay in the charter here.  The charter states:

  .. the WG will
  identify target applications to appropriately scope the problem and
  requirements. P2P applications are the primary target, but suitability
  to other applications with similar requirements may be considered
  depending on additional complexity required to support such
  applications.

The chartered work isn't "complementary" scenarios, but rather ones
with similar requirements.  In my opinion, the "do no harm" tenet can
be a good guidance to see if a particular application has similar
enough requirements.

In any case, if additional requirements are indeed being considered, I
think we need to have something concrete (e.g., a particular
application in use today).  That will tell us whether we're
approaching something with similar requirements to supporting a P2P
application, and where there might be differences in the requirements.

Rich

---

From: "David A. Bryan" <[email-masked]>
Date: Fri, 11 Jun 2010 09:55:39 -0400

The chartered focus of this WG is the P2P scenario, and has been
limited intentionally to keep the problem tractable (although as I
said, we should try to make things as flexible as possible to
encourage possible reuse). Designing a generic data storage system for
any app to store any kind of information is a far more complex
problem, because it is essentially unconstrained -- where do we draw
the line on applications? Can I use this as a backup for my server? As
a distributed file system? A real-time media streaming server for
handsets? To build a service like drop box? As a web server?

The problem becomes requirements explosion to satisfy all these
different scenarios. Your proposal to add mobility is a perfect
example of this issue. To have a generic storage a mobile client can
quickly access, you would need such a capability, but it is out of
scope explicitly (locating best storage) because it would radically
increase the complexity of the protocol in a way that would make
deployments for the original problem space much more difficult.

In my IETF experience, trying to solve many simultaneous problems is
the biggest obstacle to the success of a protocol, not being too
narrow in the design of the protocol. When we try that, we end up with
protocols that are the equivalent to an all-in-one kitchen gadget. It
blends, mixes, bakes, and of course slices, dices and juliennes, but
it doesn't do any of those things in a way that is really right.

We need to keep the focus sharp and simple, and design a solid
protocol for that task. We'll try hard to keep it flexible, but
remember that if the work is too far off, one can always have a
different WG with a different goal, and design something for that
scenario. In my personal opinion, I see your proposed requirements as
being a bit too far afield here, and believe adding them to the
requirements will increase the time to deliver a protocol and increase
the odds that protocol will fail.

David

---

From: Song Haibin <[email-masked]>
Date: Sun, 13 Jun 2010 09:55:47 +0800

I think if possible, we can divide the mobility scenario into several
detailed technical requirements. 

The first one could be copying/moving data between in-network storage, I can
see reasons to support it.

The second one I could envision is the service continuity when the IP
address of the client changes. And it should not require additional
re-authentication between the end user and the in-network storage. That
might mean, e.g. when a peer allocate the bandwidth resource in its
in-network storage for data retrieving to another peer, it should not depend
on the IP address of the remote peer.

Any other ones?

Xie Xie,
Haibin <as contributor>

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Richard Alimi
> Sent: Friday, June 11, 2010 9:02 PM