Re: [tcpm] Tuning TCP parameters for the 21st century

[Michael Scharf <[e-mail]>]

On Tue, 14 Jul 2009 at 16:02:39, Joe Touch wrote:
> Larger messages benefit as you open the window to burst the whole thing
> out. Here's a back of the envelope:
> 
> # packets	was RTTs:	is RTTs:	benefit
> 	4	2		2		0%
>  	10 	3		2		33%
> 	19	4		2		50%
> 	32	5		2		60%
> 	52	6		2		67%
> 	82	7		2		71%
> 
> Note though that at some point your SND_CWND will be opened only as far
> as the path allows, at which point sending more packets just takes more
> RTTs, so you start to lose. 90% of our max CWNDs were below 9K, which
> means we only saw benefits in the 20-30% range (i.e., the first two rows
> above). Sure, if you see CWNDs much larger, you might benefit from
> reusing old values...

A large initial SND_CWND might not result in such a large benefit if
the receiver still announces a small receive window (e. g., the Linux
stack initially announces a receive window of about 6K only). This
issue is documented in an (expired) ID:

  http://tools.ietf.org/html/draft-scharf-tcpm-flow-control-quick-start-00

An example for a limitation by the receive window can also be seen on
slide 19 of

  http://www.ietf.org/proceedings/08nov/slides/iccrg-2.pdf

Note that, at least in case of Linux, it is possible to mitigate this
limitation by an ugly hack: The sender could ignore the announced
receive window during the first RTT of the Slow-Start and
optimistically send more data. As the receiver exponentially opens the
receive window, the received packets are always within the current
receive window - if the receiver does not run out of memory. But of
course this hack violates RFC 793.

BTW: My experiments with different fast startup schemes (with and
without rate pacing) also show that the absolute benefit of a faster
startup is small for many typical Internet workloads. Yet,
applications that frequently transfer mid-sized amounts of data can
indeed benefit. And since only few applications actually use a large
initial SND_CWND, the risk of a moderate increase of the initial
window appears to be rather small. As also mentioned in my ICCRG
presentation, the "Jump-Start" idea of M. Allman et al. seems to have
a quite reasonable performance in many scenarios.

Unfortunately, I cannot back these statements by large-scale
experimental data so far. But if someone wanted to perform some
experiments, e. g., with the "Jump-Start" scheme, I could provide
corresponding Linux kernel patches.

Michael