Subject: [ledbat] draft-ietf-ledbat-survey-04

From: michawe <[email-masked]>
Date: Fri, 14 Jan 2011 17:36:57 +0100

Hi,

We have updated our survey draft, which is now available from here:
http://www.ietf.org/id/draft-ietf-ledbat-survey-04.txt

Please find our answers to the remaining reviewer comments (just Mirja, unless we missed something). Reviewers, please let us know if you think that we addressed your comments now, or if you require further changes. Thanks!

Cheers,
Michael

-----

todo list:

One small thing: NF-TCP is not introduced as 'Network-Friendly TCP'...

-- Done.

Some more high level comments:

1) I would like to RAPID Congestion Control in this document because it a new 
and really different approach in the area of delay-based congestion control.

-- We believe that adding a mechanism like RAPID, which was not designed for LBE but occasionally happens to show this behavior, is opening a can of worms. For example, in Fig.8 of the Infocom RAPID paper, it looks as if FAST would then be the next candidate to talk about. Sometimes it may be LBE - sometimes not. e.g., from our reference [Aru10]: "Fig. 9(a) illustrates that although NF-TCP has a much shorter RTT, it is friendly towards TCP flows while also opportunistically utilizing the spare bandwidth. TCP-LP (Fig. 9(c)) is also friendly to standard TCP, but is not compeletly submissive. RAPID (Fig. 9(b)) and LEDBAT (Fig. 9(d)) are both not submissive. For RAPID, this is due to the combination of its aggressive nature and its complete reliance on delay-based probing to measure available bandwidth."

(a side note: regarding LEDBAT, the authors might have evaluated an old version, I didn't check)

2) Not sure if section 2.1. is needed at all in this document as these are 
general issues about delay measurements and not especially for LBE 
transports. 

-- We think it adds value to the document because there is such a weight on the delay-based side in it. This section is also really only about measuring delay within a congestion control mechanism, not delay measurements in general. 

3) Why is there only a 'potential issues' section (2.2.) for the delay based 
approaches? I would say every approach has its issues, e.g. the non-delay 
based approaches in section 3. have to send with a certain minimum rate; they 
will never give all the available capacity to the competing TCP connection. 
Application level approach introduce often more overhead and network-assisted 
approaches require the bottleneck to cooperate.

-- Similar to the case above, we felt that this adds value because there is such a weight on the delay-based side in the document. We briefly addressed the fact that, of course, all approaches have their issues at the beginning of the respective section. e.g., in section 3, we have the statement: "such mechanisms likely cause more queuing delay and react to congestion more slowly than delay-based ones." I could come up with quite a number of other problems - e.g. corruption loss, etc.; many of these things are covered in draft-irtf-iccrg-welzl-congestion-control-open-research-08.txt. We believe that going into more details on issues of non-delay-based approaches (enough to justify adding a section of its own) would stretch this too far and make the document unnecessarily boring and hard to read.

4) In section 5 I suggest to weighted fair queuing.

-- We decide against this because the scope of our document is on *transport protocols*, i.e. protocols operating at the transport layer, i.e. protocols involving end systems. Section 5 deals with such protocols that receive assistance from the network - i.e. there is some form of design which involves the end systems and the network. This does not include pure inside-the-network approaches; e.g., RFC 3662 very explicitly introduces a LBE behavior (and so might a ton of other work, possibly even from the MPLS world!), but also doesn't fit for the reasons above.

... from Mirja's second email:

from my point of there does not need to be a comparison with only LEDBAT. For 
me it would be okay to have the pro's and con's for every approach in 
relation to each other or with a general point of view. But I would like to 
see a really short discussion for every approach that gives the reader a 
change to get a first impression in which cases which mechanism can be used 
or should not be used.

-- For LEDBAT, we now added a "Conclusion and LEDBAT considerations" section. For the rest, we think that we have covered this (short, as you say) in the first paragraph of every section in the last update.