Subject: Re: [ledbat] New Version Notification for draft-ietf-ledbat-survey-02

From: Michael Welzl <[email-masked]>
Date: Thu, 9 Dec 2010 20:51:33 +0100

Hi all,

We still haven't heard back from any volunteers... this isn't a very  
long or complicated document, it would be great to get our third and  
final volunteer to quickly review it.

Cheers,
Michael

On Dec 1, 2010, at 1:40 AM, David Ros wrote:

> Dear all,
>
> As promised in Beijing, we've posted an update to the survey draft,  
> see announcement below. Comments are welcome.
>
> Also, the chairs requested (at least) one more review; please  
> volunteer!
>
> Thanks in advance & best regards,
>
> David.
>
>
> Début du message réexpédié :
>
>> De : IETF I-D Submission Tool <[email-masked]>
>> Date : 1 décembre 2010 01:30:14 HNEC
>> À : [email-masked]
>> Cc : [email-masked]
>> Objet : New Version Notification for draft-ietf-ledbat-survey-02
>>
>>
>> A new version of I-D, draft-ietf-ledbat-survey-02.txt has been  
>> successfully submitted by David Ros and posted to the IETF  
>> repository.
>>
>> Filename:	 draft-ietf-ledbat-survey
>> Revision:	 02
>> Title:		 A Survey of Lower-than-Best-Effort Transport Protocols
>> Creation_date:	 2010-12-01
>> WG ID:		 ledbat
>> Number_of_pages: 17
>>
>> Abstract:
>> This document provides a survey of transport protocols which are
>> designed to have a smaller bandwidth and/or delay impact on standard
>> TCP than standard TCP itself when they share a bottleneck with it.
>> Such protocols could be used for delay-insensitive "background"
>> traffic, as they provide what is sometimes called a "less than" (or
>> "lower than") best-effort service.
>>
>>
>>
>> The IETF Secretariat.
>>
>>
>
> =================================================================
> David ROS
> http://www.rennes.enst-bretagne.fr/~dros/
>
> I love deadlines. I like the whooshing sound they make as they fly  
> by. -- Douglas Adams
>
>
>
>

---

From: Wesley Eddy <[email-masked]>
Date: Mon, 13 Dec 2010 21:51:44 -0500

On 11/30/2010 7:40 PM, David Ros wrote:
> Dear all,
>
> As promised in Beijing, we've posted an update to the survey draft, see announcement below. Comments are welcome.
>
> Also, the chairs requested (at least) one more review; please volunteer!
>

Here are some review comments I had.  Aside from some general ones, 
they're all editorial or possibly minor technical clarifications that 
could be made.

General / Overall

- We should have some material early on to set context; things to 
mention include:
   - intended audience (familiarity with standard TCP, RFC2581/5681, is 
assumed)
   - this was a product of the LEDBAT WG for comparison/contrast to the 
chosen approach (this needs to be mentioned, because remember that when 
the RFC is published, a casual reader won't know it came from LEDBAT 
unless you say so)
   - most techniques discussed here are tested in limited simulations or 
experimental testbeds, but LEDBAT's algorithm is already under 
widespread deployment (i.e. we need to say that we're acknowledging 
other techniques, but not advocating them here; this does not interfere 
with advancement of the LEDBAT algorithm)
   - this is not exhaustive; that wouldn't be possible or useful, but 
the authors/editors have selected key, well-known, or otherwise 
interesting techniques for inclusion at their discretion
   - was applicability to big-I Internet deployment scenarios a 
consideration?  (I think yes, but don't actually know in some of the cases)

- Does it need to be more clearly mentioned which classes of approaches 
were mechanisms incorporated in TCP, TCP-alternatives (e.g. for DCCP or 
new transports), or other designs entirely.  For instance, do they have 
subtle (or obvious) differences in the services provided to applications 
(reliability, smoothness, etc.)?  Section 4's first paragraph does a 
good job of explaining this, but other sections had me wondering 
slightly.  It may be a personal problem on my part, so it would be good 
to check with others :).

- Are there fairly common assumptions in a lot of the existing academic 
analysis cited here which influence results?  For instance, there are 
often assumptions about flow length, RTT distributions, or other 
elements that may be relevant to mention here? (e.g. all flows are FTP 
of 10 GB files, etc.)

- Should there be a (very short) conclusions section that says where 
LEDBAT fits in and the main pros/cons versus the other classes of system 
discussed?

Section 1

- (editorial) It might be more clear to replace "end-to-end mechanisms" 
with "end-host mechanisms", since end-to-end is relative.

- (editorial) The LBE acronymn is defined twice in the first paragraph; 
the second expansion at the end of the paragraph can probably either 
just use "LBE" or put the expansion in quotation marks.

Section 2

- (editorial) The second sentence of the first paragraph could be 
clarified and shortened to just "Without ECN support, standard TCP will 
normally increase its congestion window (and effective sending rate) 
until a queue overflows, causing one or more packets to be dropped and 
the effective rate to be reduced."  I didn't like the "for some reason" 
in the current sentence because there are clear reasons like application 
limited, advertised receive window limited, kernel knob limited, etc, 
but they all seem to be beside the point rather than contributing to it.

- (editorial) At one point the text capitalizes "Congestion Avoidance", 
and in others it doesn't.  I think lower-case is best.

- (editorial) "threshold beta" might be more clear as "threshold (called 
"beta")" (same comment applies for alpha)

- (minor) "actual (measured) throughput" might be more clear as "actual 
throughput measured by recent acknowledgements"

- (minor) is the increase at the end of the 3rd paragraph every RTT or 
BaseRTT (I don't recall myself)

- (minor) "maintaining the window size" should be "maintaining the 
current congestion window"

- (editorial) "it the standard" should be "it in the standard"

- (minor) What does "remain transparent to standard TCP" really mean? 
There must be a better way to word this.

Section 2.1

- (minor) under the "RTT measurement issues", is it worth mentioning the 
case of fast or short-distance links where the delay is all in the stack 
and not on the wire?

Section 2.2

- (minor) is it worth mentioning LEDBAT's sensitivity to changes in the 
route also, when we mention Vegas?  Is it purposeful that we never 
really compare/contrast to LEDBAT itself in this document?

Section 4

- (editorial) In the last paragraph, is a ":" really the best way to 
punctuate this?

Section 5

- (minor) For the network-assisted approaches, it wasn't entirely clear 
to me if these were new transport protocols or new mechanisms for 
existing transports; if that could be clarified without the reader 
needing to check the references, I think that would be good.

- (minor) Should there be a summary/conclusion sentence here about the 
current viability of such approaches?

---

From: Rolf Winter <[email-masked]>
Date: Thu, 16 Dec 2010 08:55:21 +0000

Hi,

I would also be good if the previous reviewers could assess whether their comments have been addressed or not.

Best,

	Rolf

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Michael Welzl
> Sent: Donnerstag, 9. Dezember 2010 20:52
> To: [email-masked]
> Subject: Re: [ledbat] New Version Notification for draft-ietf-ledbat-
> survey-02
> 
> Hi all,
> 
> _______________________________________________
> ledbat mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ledbat