Shady areas of TCP window autotuning?

Wed Mar 18 13:25:35 UTC 2009

In a message written on Wed, Mar 18, 2009 at 09:04:42AM +0100, Marian ??urkovi?? wrote:
> 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.

Ah, I understand your point now.  There is a balance to be had at
the edge; the tuning to support a single TCP stream at full bandwidth
and the tuning to reduce latency and jitter are on some level
incompatable; so one must strike a balance between the two.

Of course...

> 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.

Many of the problems can be mitigated with well known queueing
strategies.  WRED, priority queues, and other options have been
around long enough I refuse to believe they add significant cost.
Rather, I think the problem is of awareness, far too few network
engineers seem to really understand what effect the queuing options
have on traffic.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20090318/09a25489/attachment.sig>