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

[Arjuna Sathiaseelan <[e-mail]>]

 I agree to these points too that LEDBAT MUST NOT evolve its initial
 window to a larger value.

 To solve the issue of bursts as Joe pointed out, do we need LEDBAT to
 be rate paced (atleast during the initial phases)?

 Arjuna

> On 19 October 2011 08:26, Gorry Fairhurst <[e-mail]> wrote:
>> 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
>>
>> _______________________________________________
>> ledbat mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ledbat
>>
>
>
>
> --
> http://about.me/arjuna.sathiaseelan
>