Re: [ledbat] New Version Notification for draft-ietf-ledbat-congestion-05.txt

I reviewed the latest draft. Thanks for making all the changes and explaining the parameters. I have a few editorial comments:

- In section 4.2.2 second paragraph, the draft suggests that LEDBAT does not induce losses. Even though it is true in most cases, I am not sure if we can conclusively say that. If the queue is smaller than 100ms worth of data, there can be a loss.

- One of the implications of the size of BASE_HISTORY is that a sender will not respond to a change in delay for that many minutes if the change is due to a change in the link or route. I am not sure if it is worth mentioning that .. but I thought I'd bring it up.

-  In section 4.3.3 second paragraph, there is a typo -- "LEDBAT has been been implemented and successfully.." There has to be only one "been" :) 

Thanks,
Padma

> 
> Message: 1
> Date: Thu, 19 May 2011 21:00:53 +0000
> From: Murari Sridharan <muraris@microsoft.com>
> To: "janardhan.iyengar@fandm.edu" <janardhan.iyengar@fandm.edu>,
> 	"ledbat@ietf.org" <ledbat@ietf.org>
> Subject: Re: [ledbat] New Version Notification for
> 	draft-ietf-ledbat-congestion-05.txt
> Message-ID:
> 	<EF5EF2B13ED09B4F871D9A0DBCA463C216B03B80@TK5EX14MBXC298.redmond.corp.microsoft.com>
> 	
> Content-Type: text/plain; charset="utf-8"
> 
> Folks, we are looking to sign off on this fairly soon. This version is good enough to go to WGLC so please send your review feedback to the authors. 
> 
> Thanks
> M & R
> 
> -----Original Message-----
> From: Janardhan Iyengar [mailto:jana.iyengar@gmail.com] 
> Sent: Tuesday, May 10, 2011 3:36 PM
> To: ledbat@ietf.org
> Cc: Mirja Kuehlewind; Murari Sridharan; Rolf Winter (Rolf.Winter@neclab.eu)
> Subject: Fwd: New Version Notification for draft-ietf-ledbat-congestion-05.txt
> 
> Dear all,
> 
> A new version of the LEDBAT draft is now available online.  We've touched up some text and clarified several points about the algorithm.  We are hoping to do WGLC with this version, so please read and comment as soon as you can.
> 
> The major mods to the algo and description are:
> 
> 1. (Sec. 3.4) We've modified the MIN filter that was being used for current_delays to an unspecified filter.  The main reason was that MIN is NOT a good filter for current_delays, something like an EWMA filter is more appropriate.
> 2. (Sec. 3.3 and 3.4) We've added text to clarify how a receiver that delays acks (sends acks less frequently than once per data packet) may pack several delay samples in one ack, and we've modified the sender to deal with multiple delay samples in each ack.
> 3. (Sec. 3.5) Added a definition of the GAIN parameter, and text that separates increase-GAIN from decrease-GAIN.
> 
> Other nits:
> 
> 1. (Sec. 3.2) Added definition of "MSS" to the Preliminaries Section.
> 2. (Sec. 3.4) Fixed a bug in the cwnd increase/decrease algorithm to include an MSS factor in its computation.
> 
> Thanks!
> - jana
> 
> 
> 
> -------- Original Message --------
> Subject: New Version Notification for draft-ietf-ledbat-congestion-05.txt
> Date: Tue, 10 May 2011 15:16:42 -0700
> From: internet-drafts@ietf.org
> To: jiyengar@fandm.edu
> CC: jiyengar@fandm.edu, mirja.kuehlewind@ikr.uni-stuttgart.de,	greg@bittorrent.com, shalunov@bittorrent.com
> 
> A new version of I-D, draft-ietf-ledbat-congestion-05.txt has been successfully submitted by Janardhan Iyengar and posted to the IETF repository.
> 
> Filename:	 draft-ietf-ledbat-congestion
> Revision:	 05
> Title:		 Low Extra Delay Background Transport (LEDBAT)
> Creation date:	 2011-05-10
> WG ID:		 ledbat
> Number of pages: 17
> 
> Abstract:
>    LEDBAT is an experimental delay-based congestion control algorithm
>    that attempts to utilize the available bandwidth on an end-to-end
>    path while limiting the consequent increase in queueing delay on the
>    path.  LEDBAT uses changes in one-way delay measurements to limit
>    congestion that the flow itself induces in the network.  LEDBAT is
>    designed for use by background bulk-transfer applications; it is
>    designed to be no more aggressive than TCP congestion control and to
>    yield in the presence of any competing TCP flows, thus limiting
>    interference with the network performance of the competing flows.
> 
> 
> 
> 
> The IETF Secretariat
> 
> 
> ------------------------------
> 
> _______________________________________________
> ledbat mailing list
> ledbat@ietf.org
> https://www.ietf.org/mailman/listinfo/ledbat
> 
> 
> End of ledbat Digest, Vol 29, Issue 4
> *************************************