Re: [ledbat] INIT_CWND and MIN_CWND (WAS Re: New Version Notification for draft-ietf-ledbat-congestion-08.txt)

Ingemar, 

I agree. 

And if he shortlived flows and small bulk of data are supposed, 
it is significant to increase the window exponentially?  

Gengyu

----- Original Message ----- 
From: "Ingemar Johansson S" <ingemar.s.johansson@ericsson.com>
To: <ledbat@ietf.org>
Cc: <jana.iyengar@gmail.com>
Sent: Thursday, October 20, 2011 1:21 PM
Subject: [ledbat] INIT_CWND and MIN_CWND (WAS Re: New Version Notification for draft-ietf-ledbat-congestion-08.txt)

> Hi
> 
> Change of subject name. 
> I have no strong opinion on this but I would like to ask how likely it is that LEDBAT is used for shortlived flows in the first place. The CC-algo does not seem to me as the obvious pick of I was looking for instance for fast HTTP request/response times. Given that it seems like minor issue what the INIT_CWND is if the flows are 10minutes in duration or perhaps more.
> MIN_CWND is another matter, that should possibly be fixed to relatively small value like 2.
> 
> /Ingemar
> 
>> 
>> Message: 3
>> Date: Wed, 19 Oct 2011 10:14:53 -0700
>> From: Joe Touch <touch@isi.edu>
>> To: gorry@erg.abdn.ac.uk
>> Cc: Janardhan Iyengar <jana.iyengar@gmail.com>, ledbat@ietf.org
>> Subject: Re: [ledbat] New Version Notification for
>> draft-ietf-ledbat-congestion-08.txt
>> Message-ID: <4E9F058D.4040909@isi.edu>
>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>> 
>> Hi, Gorry,
>> 
>> I agree with your logic, but it suggests INIT_CWND and 
>> MIN_CWND should be 2 - those are both clearly safe, clearly 
>> smaller than the current deployed base, and would not 
>> increase to track TCP's increases.
>> 
>> Joe
>> 
>> On 10/19/2011 12:26 AM, Gorry Fairhurst 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
>> ledbat@ietf.org
>> https://www.ietf.org/mailman/listinfo/ledbat
>> 
>> 
>> End of ledbat Digest, Vol 33, Issue 9
>> *************************************
>> 
> _______________________________________________
> ledbat mailing list
> ledbat@ietf.org
> https://www.ietf.org/mailman/listinfo/ledbat
>