Re: [decade] Working Group Last Call: draft-ietf-decade-arch-07

["Y. Richard Yang" <[e-mail]>]

On 7/12/12 10:18 PM, Rahman, Akbar wrote:
>
> Hi,
>
> Sorry for my delay in responding.  After thinking about it, I agree 
> with all of you that optimizations are not appropriate for a base 
> architecture document.  So I propose that we delete the following 
> optimizations from the Arch I-D:
>
> -Section 4.4, 2nd to last paragraph (as initially identified by Kostas 
> in his comment (6))
>
I am fine with removing this "optimization". The effect of the proposed 
feature is to remove the "store-and-forward" delay. The word of "SHOULD" 
is a bit strong. But we may need to keep in mind that it can be an 
important feature. Such opportunistic Write/Read may not be too 
difficult to handle failures, as Kostas pointed out, if there is a 
name-data binding to validate.

> -Section 6.1.2, 2nd to last paragraph (as initially identified by 
> Kostas in his comment (8))
>
Agreed. Batch may not be necessary as in an arch doc.

> -Section 5.2.3, lasts sentence
>
Agree. One can think of multiple ways to optimize, and may not be 
limited to temporary data (e.g., write log).

Richard

> Does anyone have any objections to this approach?
>
> /Akbar
>
> *From:*Zhang Peng [mailto:[e-mail]]
> *Sent:* Friday, July 06, 2012 11:36 AM
> *To:* Stephen Farrell
> *Cc:* Rahman, Akbar; [e-mail]; Konstantinos Pentikousis
> *Subject:* Re: Re: [decade] Working Group Last Call: 
> draft-ietf-decade-arch-07
>
> Hi Stephen,
>
> I agree with you, and suggest that this optimization should not appear 
> in -arch document, since it is too detailed, and may raise more 
> concerns than it solves. Or we can use MAY instead of SHOULD to 
> indicate that this is a optional feature that are preferable, and 
> state clearly the issues that may arise (i.e., how to deal with client 
> abortion). How would others think? Thanks.
>
> B,
>
> Peng.
>
> *From:*Stephen Farrell <mailto:[e-mail]>
>
> *Date:* 2012-07-06 05:52
>
> *To:*pzhang.thu <mailto:[e-mail]>
>
> *CC:*Rahman, Akbar <mailto:[e-mail]>; 
> [e-mail] <mailto:[e-mail]>; Konstantinos Pentikousis 
> <mailto:[e-mail]>
>
> *Subject:* Re: [decade] Working Group Last Call: draft-ietf-decade-arch-07
>
> I'm not sure if designing optimisations is best done
>
> when considering requirements. It sounds like something
>
> liable to lead to premature optimisation.
>
> On 07/06/2012 02:15 AM, Zhang Peng wrote:
>
> > Hi,
>
> >
>
> > As for the comment (6) regarding optimization about naming, I think we need further discussion.
>
> >
>
> > The question is that whether the name SHOULD be generated and returned to the client before commitment to the uploading.
>
> >
>
> > First, we should evaluate the gain by using this what i term as "early name generation". Consider that a client A is uploading a object F to DECADE server D, and another client B needs to download it from D. Below is the stages to be taken without considering authentication, and access control.
>
> >
>
> > 1. A sends upload request to D, which responses with a permission
>
> > 2. A uploads F to D
>
> > 3. D returns the object name to A
>
> > 4. A advertises the object
>
> > 5. B knows the file name and request the object from D
>
> > 6. D sends the object to B
>
> >
>
> > Here 1,3,4,5 may cost constant small amount of time, while 2,6, depend on the size of object and tend to cost more time. The benefit of putting 3 before 2 is that 4 and 5 can be carried out in parallel with 2. Thus it seems that we can just save the time of 4 and 5 in this process. But considering that B is in different locations, and using another DECADE sever E, then we can also save the time for E request the object from D. In addition, It may also take more time if we consider the case that A should advertise to a lot of interested receivers, which may consume more time. Without this non-quantitative analysis, it seems that it can benefits the live applications to reduce the latency. But the benefits are not so clear, and may depend on applications.
>
> Putting "3 before 2" wouldn't be the only option though.
>
> For example, A could upload Hash(F) which might be used in
>
> generating the object name at step 1. There are many ways
>
> to do things, setting up requirements that things be done
>
> in one way seems like a bad plan to me.
>
> S.
>
> > If we would include this in -arch as a design requirements, we need to handle some erroneous situations, just as mentioned by Kostas. When the client advertises a object, but does not upload or finish the uploading, the DECADE server, however, may have already grant the object or send the part of the object to some receiver. Then the server should just sends a error signal to the granted receivers, or let the receivers timeout themselves, and delete the object. Retransmission may or may not happen, depending on the application implementation.
>
> >
>
> > I am still not quite sure whether the potential benefits of this optimization worth the complication it brings. More discussion may be needed. Thanks.
>
> >
>
> > B,
>
> >
>
> > Peng.
>
> >
>
> >
>
> > From: Rahman, Akbar
>
> > Date: 2012-07-05 01:21
>
> > To: [e-mail]
>
> > CC: Konstantinos Pentikousis
>
> > Subject: Re: [decade] Working Group Last Call: draft-ietf-decade-arch-07
>
> > Hi,
>
> >
>
> >
>
> > The DECADE Architecture authors were contacted off list by Kostas who
>
> > provided the following relevant and useful comments on the
>
> > draft-ietf-decade-arch-07.  We intend to address these comments in the
>
> > next revision of the architecture I-D after the WGLC ends.
>
> >
>
> > 1) Figure 1:
>
> > This figure and the accompanying text (as-is right now) leaves quite
>
> > some room for interpretation. For example,  two distinct
>
> > "DECADE-compatible" systems deployed by two different operators may have
>
> > DRP1 vs. DPR2, in addition to having multiple SDTxyz's. Is this what you
>
> > have in mind?
>
> >
>
> >
>
> > 2) Section 4.2, Referring to the word "multipath":
>
> > I think you mean multi-source here? Multipath is mostly related with two
>
> > (multihomed) end nodes and routing in the network rather than one node
>
> > getting bits and pieces of a data object from different sources (as in
>
> > P2P). You can still have multipath and single-source.
>
> >
>
> >
>
> > 3) Section 4.2, third paragraph, first sentence:
>
> > As per the sec. 2.8, a "data object is a string of raw bytes".
>
> > Therefore, in this sentence we need s/SHOULD/MUST.
>
> >
>
> >
>
> > 4) Section 4.2, third paragraph, second sentence:
>
> > This may introduce the issue of MDO discovery (max data object), when
>
> > one connects to different DECADE Servers, perhaps along the lines of MTU
>
> > discovery. Content resegmentation is not covered in this section, esp.
>
> > since a DECADE server may store/maintain DOs from completely different
>
> > apps.
>
> >
>
> >
>
> > 5) Section 4.2, last paragraph:
>
> > The introduction of the "block" may be redundant here. A block is,
>
> > similarly to a DO, "a string of raw bytes", isn't it? If not, we need a
>
> > formal definition for it. Of course, the key aspect here is what can you
>
> > name and locate in a DECADE Server, and my reading of the ID so far is
>
> > that you have settled on the use of the DO, irrespective of the
>
> > application semantics. The repeated use of "block" here and there simply
>
> > confuses the uninitiated reader.
>
> >
>
> >
>
> > 6) Section 4.4, 2nd to last paragraph:
>
> > I think the optimization described in this paragraph is not particularly
>
> > suited for the Architecture document. And it opens up all kinds of
>
> > questions.  E.G. what if the host advertizing an object crashes before
>
> > it uploads the object? What if the host changes its mind during the
>
> > upload? Since we're talking about immutable objects, shouldn't we wait
>
> > until an object is "committed". In the end, this optimization could be
>
> > counter-productive in these cases. Let alone the fact that the scenarios
>
> > for which DECADE is envisaged (and motivated from I would add) tend to
>
> > have asymmetric capacities in down/uplink, perhaps of a ratio of 10:1.
>
> > Thus, downloading is not typically the performance bottleneck. Perhaps I
>
> > am wrong in thinking of this as a premature optimization though. Can you
>
> > provide examples from exisiting apps that follow this proposal (and how
>
> > do they handle error cases)?
>
> >
>
> > Moreover, using SHOULD for such a optimization may not be a good idea in
>
> > the general case.
>
> >
>
> >
>
> > 7) Figure 3:
>
> > This figure implies that multiple applications will need to implement
>
> > their own DECADE client, which cannot be shared at run time with other
>
> > apps. Of course one could see this as including/linking to a library,
>
> > but perhaps a more flexible implementation could also be thought of,
>
> > based, for example, on a DECADE "platform", shared by many apps at run
>
> > time.
>
> >
>
> >
>
> > 8) Section 6.1.2, second to last paragraph:
>
> > This proposed optimization need not be part of the "architecture"
>
> >
>
> >
>
> > 9) Section 6.1.3:
>
> > Wouldn't it be better to skip this section altogether and consider an ID
>
> > on management aspects instead? For example, why not simply define an MIB
>
> > for DECADE and use existing methods to obtain this status info? Why add
>
> > more complexity in DRP implementations?
>
> >
>
> >
>
> > 10) Section 10.2:
>
> > http://dx.doi.org/10.1145/1544012.1544078 should also be added here, as
>
> > it motivates well the domain considered in this architecture, including
>
> > the DO.
>
> >
>
> >
>
> > 11) Various editorial and grammatical fixes (which were provided to the
>
> > authors off line).
>
> >
>
> >
>
> > Many thanks to Kostas for providing these excellent comments.
>
> >
>
> >
>
> > Akbar
>
> >
>
> >
>
> > -----Original Message-----
>
> > From: [e-mail] [mailto:[e-mail]] On Behalf
>
> > Of Songhaibin
>
> > Sent: Wednesday, June 20, 2012 10:06 PM
>
> > To: [e-mail]
>
> > Subject: [decade] Working Group Last Call: draft-ietf-decade-arch-07
>
> >
>
> > Dear folks,
>
> >
>
> > After the first round of the last call, the architecture document has
>
> > many changes to resolve comments from reviewers as well as area director
>
> > and experts from other areas. Thanks to the reviewers and the authors.
>
> >
>
> > So Rich and I now start another round of WGLC on
>
> > draft-ietf-decade-arch-07, ending Friday, July 6th. Please review the
>
> > document and reply with your comments.
>
> >
>
> > Thanks,
>
> >
>
> > -Haibin and Rich (co-chairs)
>
> >
>