Re: [PATCH] Make CUBIC Hystart more robust to RTT variations

[Stephen Hemminger <shemminger@vyatta.com>]

On Wed, 9 Mar 2011 19:25:05 +0100
Lucas Nussbaum <lucas.nussbaum@loria.fr> wrote:

> On 09/03/11 at 09:56 -0800, Stephen Hemminger wrote:
> > On Wed, 9 Mar 2011 07:53:19 +0100
> > Lucas Nussbaum <lucas.nussbaum@loria.fr> wrote:
> > 
> > > On 08/03/11 at 20:30 -0500, Injong Rhee wrote:
> > > > Now, both tools can be wrong. But that is not catastrophic since
> > > > congestion avoidance can kick in to save the day. In a pipe where no
> > > > other flows are competing, then exiting slow start too early can
> > > > slow things down as the window can be still too small. But that is
> > > > in fact when delays are most reliable. So those tests that say bad
> > > > performance with hystart are in fact, where hystart is supposed to
> > > > perform well.
> > > 
> > > Hi,
> > > 
> > > In my setup, there is no congestion at all (except the buffer bloat).
> > > Without Hystart, transferring 8 Gb of data takes 9s, with CUBIC exiting
> > > slow start at ~2000 packets.
> > > With Hystart, transferring 8 Gb of data takes 19s, with CUBIC exiting
> > > slow start at ~20 packets.
> > > I don't think that this is "hystart performing well". We could just as
> > > well remove slow start completely, and only do congestion avoidance,
> > > then.
> > > 
> > > While I see the value in Hystart, it's clear that there are some flaws
> > > in the current implementation. It probably makes sense to disable
> > > hystart by default until those problems are fixed.
> > 
> > What is the speed and RTT time of your network?
> > I think you maybe blaming hystart for other issues in the network.
> 
> What kind of issues?
> 
> Host1 is connected through a gigabit ethernet LAN to Router1
> Host2 is connected through a gigabit ethernet LAN to Router2
> Router1 and Router2 are connected through an experimentation network at
> 10 Gb/s
> RTT between Host1 and Host2 is 11.3ms.
> The network is not congested.

By my calculations (1G * 11.3ms) gives BDP of 941 packets which means
CUBIC would ideally exit slow start at 900 or so packets. Old CUBIC
slowstrart of 2000 packets means there is huge overshoot which means
large packet loss burst which would cause a large CPU load on receiver
processing SACK.

I assume you haven't done anything that would disable RFC1323
support like turn off window scaling or tcp timestamps.


--