PC Bozo's World bites again (CNN, too)

Vadim Antonov avg at pluris.com
Thu May 28 07:09:35 UTC 1998


On Wed, 27 May 1998, Michael Dillon wrote:
> 
> Most people are changing the MTU to speed up web browsing which is data
> intensive, not interactive. I think Karl's explanation of broken Windows
> TCP/IP stacks is more likely the root cause of the problem.
>
> But has anyone ever done a proper test of this with sniffers at both the
> client end of the network and the webserver end of the network?

I don't know, but dropped or corrupted large packets is the reliable
indicator
of the flow control problems on async lines.  I saw that million times,
and
that explanation is a lot more plausible than misterious bugs.  The
reason
why broken flow control affects TCP performance is very simple: most
dialup
modems have buffers from 2 to 4 kilobytes.  Now, given the large
disparity
in speed of dialup line and the serial port, that buffer limits window
size
to 2-3 large packets, with single packet lost due to modem buffer
overflow
every round-trip time.  I.e. the steady-mode packet loss is 15-30%. 
Reducing
MTU allows window to grow to 6-10 packets, thus reducing steady-mode
packet
loss to 3-5%.

The real answer is: fix the !#@! CTS/RTS, so the buffering occurs in
the host memory. 
 
(BTW, the recommendation to reduce MTU to increase interactive
performance is
only valid when connection is shared between interactive and
non-interactive
traffic.  This is clearly not the case.)

--vadim
Who still remembers debugging 4800 bps backbone lines.



More information about the NANOG mailing list