Re: [decade] Merge requirements documents?

["David A. Bryan" <[e-mail]>]

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

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