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

[Joe Touch <[e-mail]>]

Hi, Gorry (et al.),

On Oct 15, 2011, at 12:41 AM, Gorry Fairhurst wrote:

> The latest text for the LEDBAT draft says:
> 
>   INIT_CWND SHOULD be 4, and MIN_CWND SHOULD be 2.  An INIT_CWND of 4
>   should help seed FILTER() at the sender when there are no samples at
>   the beginning of a flow, and a MIN_CWND of 2 allows FILTER() to use
>   more than a single instantaneous delay estimate while not being too
>   aggressive.  Slight deviations may be warranted, for example, when
>   these values of MIN_CWND and INIT_CWND interact poorly with the
>   framing protocol.
> 
> I commented previously on this, and here are my thoughts on the new text.
> 
> I would personally be OK with starting with a window of 4.
> 
> I do not agree that an update to TCP should be tracked by LEDBAT in the general case, because as I understand, the value 4 is derived from the operation of LEDBAT itself - i.e. use of the filter.

Sec 3.2:

   In addition to the LEDBAT mechanism described below, we note that a
   slow start mechanism can be used as specified in [RFC5681].  Since
   slow start leads to faster increase in the window than that specified
   in LEDBAT, conservative congestion control implementations employing
   LEDBAT may skip slow start altogether and start with an initial
   window of INIT_CWND * MSS.  (INIT_CWND is described later in
   Section 3.5.)

Sec 3.5:
   A LEDBAT sender uses the current_delays list to maintain only delay
   measurements made within a RTT amount of time in the past, seeking to
   eliminate noise spikes in its measurement of the current one-way
   delay through the network.  The size of this list, CURRENT_FILTER,
   may be variable, and depends on the number of successful measurements
   made within a RTT amount of time in the past.  The sender should seek
   to gather enough delay samples in each RTT so as to have statistical
   confidence in the measurements.  While the number of delay samples
   required for such confidence will vary depending on network
   conditions, we recommend that the sender SHOULD use at least 4
   samples in each RTT, unless the number of samples is lower due to a
   small congestion window.  Thus, subject to congestion window
   constraints, the number of delay samples in each RTT SHOULD be at
   least 4, and thus CURRENT_FILTER SHOULD be at least 4.
   CURRENT_FILTER MUST be limited such that samples in the list are not
   older than an RTT in the past.

   INIT_CWND SHOULD be 4, and MIN_CWND SHOULD be 2.  An INIT_CWND of 4
   should help seed FILTER() at the sender when there are no samples at
   the beginning of a flow, and a MIN_CWND of 2 allows FILTER() to use
   more than a single instantaneous delay estimate while not being too
   aggressive.  Slight deviations may be warranted, for example, when
   these values of MIN_CWND and INIT_CWND interact poorly with the
   framing protocol.

For INIT_CWND, the number 4 is derived from a notion of the minimum number of samples needed to make FILTER work. However, it clearly should not be larger than TCP's INIT_CWND, and the number 4 appears to be related to a misunderstanding of TCP's initial value (see below), not picked solely for its ability to generate meaningful statistics.

IMO, the right description would be:

	no smaller than needed to ensure a reasonable number of samples
	no larger than TCP's current values

Note that the definition of "reasonable number of samples" can be described more clearly as, e.g.,

	SHOULD use enough saamples to yield a variance of less than 25% 

I'm not sure whether "variance" or some other confidence interval should be specified, or whether 25% is better than other values. However, the current text is vague on both points.

> In general, I like the idea of explaining when the SHOULD may be violated and what the implications are. However, the present clause at the end of this para seems to suggest ANY other value could also be OK, I do not agree this is to be left to the implementer - I was hoping here to see this limited to a fraction of the current TCP initial window, e.g. "but SHOULD NOT be larger than Max (4, one half of the initial window specified for TCP, currently [RFC3390])." However, I suspect that starting small is a very good idea for a longer-lived background flow that intends to be less aggressive than other flows, and should have little impact on the overall download time, therefore it may be better to just leave the recommendation as should use 4 in the first RTT.
> 
> Gorry

Unfortunately, the equation above yields a current value of 1 (RFC3990 is 4 MSS *or* 4KB, whichever is smaller, and for 1500-byte MTUs that is 3; half of 3 would round down to 1).

Even picking TCP's current INIT_CWND should be 3, not 4, based on typical MSS sizes.

So this analysis indicates a big problem with INIT_CWND in LEDBAT - the smallest viable value needs to be large enough to have a meaningful average, but lower than TCP's INIT_CWND, and there doesn't appear to be a currently viable value.

Further, INIT_CWND should always be divisible by the ACK frequency (e.g., if 1 ACK per 2 MSS, then divisible by 2), to avoid unnecessary delays due to the ACK frequency compression.

MIN_CWND IMO should be defined as half INIT_CWND, *NOT* as a fixed value in this doc.

Joe



> On 10/10/2011 18:46, Joe Touch wrote:
>> 
>> 
>> On 10/10/2011 9:46 AM, Mirja Kuehlewind wrote:
>>> Hi,
>>> 
>>> I wouldn't want to refer to TCP's value because of a less-than-best-effort
>>> traffic there might always be a motivation to take different/lower values
>>> than TCP.
>> 
>> The values currently suggested are TCP's current values. I don't mind if you want to pick smaller ones, but I'd suggest spec'ing them relative to TCP's current values regardless.
>> 
>> Joe
>> 
>>> 
>>> Mirja
>>> 
>>> 
>>> On Monday 10 October 2011 16:37:31 Joe Touch wrote:
>>>> On 10/9/2011 4:51 PM, Janardhan Iyengar wrote:
>>>>> Dear all,
>>>>> 
>>>>> A new version of the congestion control draft is in the repository.
>>>>> There are two major mods in this revision:
>>>> 
>>>> ...
>>>> 
>>>>> 2/ We have set the values for INIT_CWND to 4 and MIN_CWND to 2, and have
>>>>> clarified the discussion of CURRENT_DELAYS and INIT_CWND/MIN_CWND in
>>>>> Section 3.5.
>>>> 
>>>> It might be more stable to refer to TCP's INIT_CWND and MIN_CWND values,
>>>> i.e., that ledbat should use TCP's values for these.
>>>> 
>>>> (they've been under discussion for revision in TCPM, FWIW)
>>>> 
>>>> Joe
>>>> _______________________________________________
>>>> ledbat mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/ledbat
>>> 
>>> 
>>> 
>> _______________________________________________
>> ledbat mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ledbat
>> 
>>