[17236] in North American Network Operators' Group
Re: PC Bozo's World bites again (CNN, too)
daemon@ATHENA.MIT.EDU (Vadim Antonov)
Thu May 28 03:17:39 1998
Date: Thu, 28 May 1998 00:09:35 -0700
From: Vadim Antonov <avg@pluris.com>
To: ken emery <ken@cnet.com>
CC: Michael Dillon <michael@memra.com>, nanog@merit.edu
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.
