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

From: "Rahman, Akbar" <[email-masked]>
Date: Thu, 5 Jul 2012 01:21:12 -0400

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: [email-masked] [mailto:[email-masked]] On Behalf
Of Songhaibin
Sent: Wednesday, June 20, 2012 10:06 PM
To: [email-masked]
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)

---

From: "Zhang Peng" <[email-masked]>
Date: Thu, 5 Jul 2012 21:15:56 -0400

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. 

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: [email-masked]
CC: Konstantinos Pentikousis
Subject: Re: [decade] Working Group Last Call: draft-ietf-decade-arch-07
Hi,

1) Figure 1: 

7) Figure 3:

9) Section 6.1.3:

10) Section 10.2:

Akbar

-----Original Message-----

Dear folks,

Thanks,

---

From: Songhaibin <[email-masked]>
Date: Fri, 6 Jul 2012 09:30:42 +0000

Thanks to Akbar for posting Kostas's comments to the list.

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Rahman, Akbar
> Sent: Thursday, July 05, 2012 1:21 PM
> To: [email-masked]
> Cc: Konstantinos Pentikousis

I think this needs clarification in the text. IMO DRP is one protocol that allows variable parameters, so there should be no interoperation problems. For SDT, in early discussion in the working group and also in the Charter, it allows multiple SDTs, so one mandatory SDT would be specified in a protocol document for interoperation. (The mandatory SDT was specified in the architecture document, but the consensus in the WG was to remove it as this document is the architecture.)

> P2P). You can still have multipath and single-source.

IMO the understanding is right.

> since a DECADE server may store/maintain DOs from completely different

Make sense to me. IP packet segmentation may cause problems for NAT traversal. But I'm still not sure. Any thoughts from others?

BR,
-Haibin

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 06 Jul 2012 10:52:39 +0100

I'm not sure if designing optimisations is best done
when considering requirements. It sounds like something
liable to lead to premature optimisation.

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

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.

---

From: "Zhang Peng" <[email-masked]>
Date: Fri, 6 Jul 2012 11:35:39 -0400

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
Date: 2012-07-06 05:52
To: pzhang.thu
CC: Rahman, Akbar; [email-masked]; Konstantinos Pentikousis
Subject: Re: [decade] Working Group Last Call: draft-ietf-decade-arch-07

S.

---

From: "Rahman, Akbar" <[email-masked]>
Date: Thu, 12 Jul 2012 10:18:05 -0400

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:[email-masked]] 
Sent: Friday, July 06, 2012 11:36 AM
To: Stephen Farrell
Cc: Rahman, Akbar; [email-masked]; 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:[email-masked]> 

Date: 2012-07-06 05:52

To: pzhang.thu <mailto:[email-masked]> 

CC: Rahman, Akbar <mailto:[email-masked]> ;
[email-masked]; Konstantinos Pentikousis
<mailto:[email-masked]> 

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

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

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.

---

From: "Y. Richard Yang" <[email-masked]>
Date: Thu, 12 Jul 2012 23:25:21 +0800

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

> *From:*Zhang Peng [mailto:[email-masked]]
> *Sent:* Friday, July 06, 2012 11:36 AM
> *To:* Stephen Farrell
> *Cc:* Rahman, Akbar; [email-masked]; Konstantinos Pentikousis
> *Subject:* Re: Re: [decade] Working Group Last Call: 
> 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:[email-masked]>
>
> *Date:* 2012-07-06 05:52
>
> *To:*pzhang.thu <mailto:[email-masked]>
>
> *CC:*Rahman, Akbar <mailto:[email-masked]>; 
> [email-masked] <mailto:[email-masked]>; Konstantinos Pentikousis 
> *Subject:* Re: [decade] Working Group Last Call: draft-ietf-decade-arch-07
>

---

From: "Rahman, Akbar" <[email-masked]>
Date: Thu, 12 Jul 2012 12:00:01 -0400

Thank you, Richard, for confirming and supporting the change.

Akbar

From: Y. Richard Yang [mailto:[email-masked]] 
Sent: Thursday, July 12, 2012 11:25 AM
To: Rahman, Akbar
Cc: pzhang.thu; Stephen Farrell; [email-masked]; Konstantinos
Pentikousis
Subject: Re: [decade] Working Group Last Call: draft-ietf-decade-arch-07

	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

Richard

/Akbar

Hi Stephen,

B,

Peng.

Date: 2012-07-06 05:52

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&nbs! p;take&nbs p;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. 

S.

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&nbs! p;happen,& nbsp;depending on the application implementation.