Shady areas of TCP window autotuning?

Wed Mar 18 08:04:42 UTC 2009

On Tue, 17 Mar 2009 10:39:13 -0500, Leo Bicknell wrote
> > So at the end of the day, we'll again have a system which is unable to
> > achieve good performance over high BDP paths, since with reduced buffers
> > we'll have an underbuffered bottleneck in the path which will prevent full
> > link untilization if RTT>50 msec. Thus all the above exercises will end up
> > in having almost the same situation as before (of course YMMV).
> 
> This is an incorrect conclusion.  The host buffer has to wait for
> an RTT for an ack to return, so it has to buffer a full RTT of data
> and then some.  Hop by hop buffers only have to buffer until an
> output port on the same device is free. 

[snip]

> However, if the hop-by-hop buffers are filling and there is lag and
> jitter, that's a sign the hop-by-hop buffers were always too large.
> 99.99% of devices ship with buffers that are too large.

Vendors size the buffers according to principles outlined e.g. here:

http://tiny-tera.stanford.edu/~nickm/papers/sigcomm2004.pdf

It's fine to have smaller buffers in the high-speed core, but at the edge you
still need to buffer for full RTT if you want to fully utilize the link with
TCP Reno. Thus my conclusion holds - if we reduce buffers at the bottleneck
point to 50 msec, flows with RTT>50 msec would suffer from reduced throughput.

Anyway we probably have no other chance in situations when the only available
queueing is FIFO. And if this gets implemented on larger scale, it could even
have a positive side-effect - it might finally motivate OS maintainers to
seriously consider deploying some delay-sensitive variant of TCP since Reno
will no longer give them the best results.

        M.