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

[Gorry Fairhurst <[e-mail]>]

On 18/10/2011 20:27, Joe Touch wrote:
>
>
> On 10/18/2011 8:29 AM, David Ros wrote:
> ...
>> Hi all,
>>
>> Sorry if I'm getting this totally wrong, but: is it really
>> *necessary*
>> that LEDBAT's INIT_CWND be *smaller* than TCP's? As far as I understand,
>> the point of LEDBAT is to be less-than-best-effort over (relatively)
>> long timescales, or at least over time scales longer than one (initial)
>> RTT. And just starting up as TCP won't make it *more* aggressive than
>> TCP. Is this correct??
>
> No, but it could make it a lot like TCP if the offered load is in short
> bursts. If that's not the intent, then the INIT_CWND needs to be smaller
> than TCP's.
>
> Joe
>
>

I think INIT_CWND should not be significantly bigger than *deployed* TCP 
INIT_CWND. (It may of course be desirable to be smaller or the same, and 
that would benefit in the way Joe suggested).

When I suggested "4" could be OK, this was only 1 larger than current 
usage for a 1500B MTU, and equivalent for some smaller MTU. That to me 
is not "significantly bigger". It would seem OK, because if this induced 
congestion LEDBAT would react within INIT_CWND segments in a 
conservative way.

If we care about LEDBAT being conservative compared to other TCP 
sessions, then I really think we should not track future new proposals 
to raise INIT_CWND. I suggest this would have side effects:

- It could make LEDBAT more aggressive than *deployed* TCP 
implementations, that I think would be bad.

- It may require LEDBAT to implement additional algorithms to ensure it 
is conservative when the larger INIT_CWND induces congestion. Addressing 
this would likely add complexity to LEDBAT and make it dependent on 
these TCP updates (if any).

I think a larger INIT_CWND (e.g. by tracking any evolution of TCP's 
INIT_CWND) is unwarranted if the goal is for LEDBAT to target  bulk 
less-than-best-effort use. I cannot see the case yet for a LEDBAT 
INIT-CWND beyond 4. Raising this could indeed save an RTT at the start 
of a LEDBAT flow, but this would be at the expense of making it 
(slightly) more aggressive than presently deployed TCP. This seems 
undesirable.

I also suggested that MIN_CWND should similarly be fixed to a small number.

Gorry