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

From: Ingemar Johansson S <[email-masked]>
Date: Thu, 20 Oct 2011 07:21:16 +0200

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 <[email-masked]>
> To: [email-masked]
> Cc: Janardhan Iyengar <[email-masked]>, [email-masked]
> Subject: Re: [ledbat] New Version Notification	for
> 	draft-ietf-ledbat-congestion-08.txt
> Message-ID: <[email-masked]>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ledbat
> 
> 
> End of ledbat Digest, Vol 33, Issue 9
> *************************************
>

---

From: "Gengyu WEI" <[email-masked]>
Date: Thu, 20 Oct 2011 15:19:49 +0800

Ingemar, 

I agree. 

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

Gengyu

---

From: David Ros <[email-masked]>
Date: Thu, 20 Oct 2011 10:35:34 +0200

Hi,

INIT_CWND = MIN_CWND = 2 sounds reasonable, and it seems to take care of the points raised -- including apps that generate nothing but short flows using LEDBAT (seems like a bad choice of CC for such apps, IMHO) -- except one.

The only thing remaining would be the filtering of delay values (the draft says INIT_CWND = 4 to initialize the filter in the first RTT), but I'd venture that this is not necessary? i.e. taking a bit more time to seed the filter doesn't look as if it'll break LEDBAT's CC?

Thanks,

David.

>>> I also suggested that MIN_CWND should similarly be fixed to 

=================================================================
David ROS
http://www.rennes.enst-bretagne.fr/~dros/

"It would seem that you have no useful skill or talent whatsoever," he said. "Have you thought of going into teaching?" -- Terry Pratchett

---

From: Joe Touch <[email-masked]>
Date: Thu, 20 Oct 2011 10:29:29 -0700

On 10/19/2011 10:21 PM, Ingemar Johansson S wrote:
> 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.

INIT_CWND comes into play during any restart, e.g., after a gap in the 
offered load.

While I don't expect LEDBAD would be used primarily for shortlived flows:
	1) we can't know that, so should plan accordingly
	2) long-lived flows with frequent gaps do exist, and
	should not cause a problem either

Joe

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 20 Oct 2011 19:15:14 +0100

> INIT_CWND comes into play during any restart, e.g., after a gap in the
Is that the "restart window" (RW) in TCP?

> should not cause a problem either
I agree with both of these.

Gorry

---

From: David Ros <[email-masked]>
Date: Thu, 20 Oct 2011 20:57:04 +0200

Le 20 oct. 2011 à 19:29, Joe Touch a écrit :

> INIT_CWND comes into play during any restart, e.g., after a gap in the offered load.
> 

Isn't that the role of max_allowed_cwnd, instead?

(section 3.4.2)
This algorithm restricts cwnd growth after a period of inactivity,
  where the cwnd is clamped down to a little more than flightsize using
   max_allowed_cwnd

Thanks,

David.

In theory, theory and practice are the same. In practice, they are different. -- Author unknown

---

From: Joe Touch <[email-masked]>
Date: Thu, 20 Oct 2011 13:25:48 -0700

> Isn't that the role of max_allowed_cwnd, instead?

That's the highest the window goes to under steady load; INIT is where 
it starts for new connections and after slow-start restart.

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 20 Oct 2011 13:28:19 -0700

> Is that the "restart window" (RW) in TCP?

Yes.

Per RFC 2581:

    For the purposes of this standard, we define RW = IW.

LEDBAT doesn't do otherwise, so that's why I've been assuming the same.

Joe

---

From: Ingemar Johansson S <[email-masked]>
Date: Fri, 21 Oct 2011 08:13:12 +0200

OK

To me it seems like Initial window = 2 is reasonable.

Regards
Ingemar

> -----Original Message-----
> From: David Ros [mailto:[email-masked]] 
> Sent: den 20 oktober 2011 20:57
> To: Joe Touch
> Cc: Ingemar Johansson S; [email-masked]; [email-masked]
> Subject: Re: [ledbat] INIT_CWND and MIN_CWND (WAS Re: New 
> Version Notification for draft-ietf-ledbat-congestion-08.txt)
> 
>

---

From: Mirja Kuehlewind <[email-masked]>
Date: Fri, 28 Oct 2011 15:28:52 +0200

Hi all,

thanks for you feedback. We will change the INIT_CWND in the draft. 
Furthermore we have to check if this has any consequences for the part 
talking about the filter. But I guess this issue can be regarded as solved 
now.

Mirja

On Friday 21 October 2011 08:13:12 Ingemar Johansson S wrote:
> > >> I have no strong opinion on this but I would like to ask
> >
> > how likely
> >
> > > INIT_CWND comes into play during any restart, e.g., after a
> >
> > gap in the offered load.
> >
> >
> > > While I don't expect LEDBAD would be used primarily for
> >
> > shortlived flows:

-- 
-------------------------------------------------------------------
Dipl.-Ing. Mirja Kühlewind
Institute of Communication Networks and Computer Engineering (IKR)
University of Stuttgart, Germany
Pfaffenwaldring 47, D-70569 Stuttgart

tel: +49(0)711/685-67973
email: [email-masked]
web: www.ikr.uni-stuttgart.de
-------------------------------------------------------------------