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

["Rahman, Akbar" <[e-mail]>]

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

-          Section 6.1.2, 2nd to last paragraph (as initially identified
by Kostas in his comment (8))

-          Section 5.2.3, lasts sentence

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]; 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)

>