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

Mailman List Mirror (Read Only)
1

Check http://cnn.com/TECH/computing/9805/26/net.access.idg/index.html

Those bozos are suggesting to reduce MTU from 1500 to 576
to "improve performance", so packets "won't fragment in
backbones"! The bright idea to fix CTS/RTS setting didn't
come along in their brilliant minds.

Here goes the average packet size. Down the drain...

Now what do we do to control the damage?

I also think it's a good time to measure the gullibilty of
the general public by measuring packet size distribution :slight_smile:

--vadim

2

This is hardly an operational issue.

That said, I think CNN messed up their explanation rather
than giving wrong advice.

Some of the original RFCs for SLIP and PPP, as well as
Stevens in TCP/IP Illustrated Volume I, pointed out
that lower mtu's on dialup lines could significantly
improve latency for interactive traffic while having
only a small efficiency loss for data intensive traffic.

The key was that you didn't want small high-priority packets
to be waiting in a queue while larger full-size mtu packets
were being sent.

Matt

Vadim Antonov wrote:

3

Yes, doing this really does work, and really does improve performance - for
Win95. The reason it does has nothing to do with fragmentation (they got
that part wrong); the reason has to do with poor handling of larger packets
in the IP stack and what I can only consider to be bugs in their code.

Cut the MTU, get rid of the problem, and the system "seems" faster on the
Internet. The reason is that you aren't dropping frames on the floor
any longer.

Does it suck in REALITY for the network packet size averages? Yes.

Does this have anything to do with CTS/RTS and flow control? Nope. Its a
genuine, no-bullshit, honest-to-god probelm in the code that is worked around
by doing this.

Go talk to Mister Softee about the millions of copies of Win95 that are out
there IP stacks that make this an "optimization". But until then, expect it
to be done, because it really does make the connection work better.

4

That said, I think CNN messed up their explanation rather
than giving wrong advice.

I don't think so. They even said in their article that the technical
details are based upon this URL
http://www.sns-access.com/~netpro/maxmtu.htm
and this guy says stuff like:

    And, it turns out, depending on how your ISP and other routers
    encountered on the Internet handle your TCP/IP requests, that a MaxMTU
    setting of 576, often referred to as the "Internet Standard", will in
    many cases avoid the fragmentation of packets of data and the slow
    transfer speeds which result.

Stevens in TCP/IP Illustrated Volume I, pointed out
that lower mtu's on dialup lines could significantly
improve latency for interactive traffic while having
only a small efficiency loss for data intensive traffic.

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?

5

Yes, and like Karl said things work better with the smaller MTU (like it
or not). Adjusting other TCP parameters is also a good idea on your servers
(although things are better now, *nix boxes of a few years ago just weren't
tuned to be used with 14.4 and 28.8 modems).

bye,
ken emery

6

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.

7

Cut the MTU, get rid of the problem, and the system "seems" faster on the
Internet. The reason is that you aren't dropping frames on the floor
any longer.

Yup. I got an apparent 12% faster connection and reduced packet loss by
setting my MTU to 576 (using MTUSpeed, a handy little program).

Does this have anything to do with CTS/RTS and flow control? Nope. Its a
genuine, no-bullshit, honest-to-god probelm in the code that is worked

around

by doing this.

The official explanation is that W95 (and W98, as far as I can tell) has
packet sizes set to 1500 for Ethernet LAN transmission and uses the same
sizes for Internet TCP/IP connections. If you're not on an Ethernet,
adjusting the MTU gives you a better 'Net connection.

Spam(tm) is pressed meat. Spammers should be too.

Dean Robb
PC-Easy
On-site computer services
(757) 495-EASY [3279]

8

Michael Dillon <michael@memra.com> writes:

I don't think so. They even said in their article that the technical
details are based upon this URL
http://www.sns-access.com/~netpro/maxmtu.htm
and this guy says stuff like:

    And, it turns out, depending on how your ISP and other routers
    encountered on the Internet handle your TCP/IP requests, that a MaxMTU
    setting of 576, often referred to as the "Internet Standard", will in
    many cases avoid the fragmentation of packets of data and the slow
    transfer speeds which result.

He used to be one of my users, at two different ISPs, in fact. I
had a long drawn out disagreement about how this was wrong, and
mathematically didn't make any sense.

However, lots of people have confirmed that it really does
help... which leads me to accept Karl's explanation.

We shouldn't expect anymore from microsoft, really.

Darrell

9

I will get into this for only a second...

I might suggest two reason why this MTU setting works...
These are based on legacy information for a *long* time
ago...
Take it with a grain of salt.

In the real old days, we had x-modem file transfers...
This X-modem transfer worked, however it had some
limitations...
It was working in 128 byte packets... This incurred an
enormous
overhead... So we came out with X-modem-CRC, and then
Y-modem,
and then Z-modem..

With each of these protocols we reduced the total overhead,
by increasing the length of the data payload. So now, on
close
systems, Zmodem was *fast*....

However, on long-distance it was slower than X...
It seems on long distance something in the circuit would
"chop a piece" here and there...
Greater distance = greater chance of error, and also a
higher
probability of hitting a mux. (Which may result in mulching)

The longer the haul, the higher the probability a packet had
to be
re-transmitted... The larger the packet, the greater the
time for recovery, and the greater the amount of data that
will need re-transmitting.

This still holds true.. In a network with lossful state,
smaller packets are better. Smaller chunks are wacked at a
time, recovery is more efficient.

Now, it seems to me this smaller MTU will work better for
dialup because:

1: Your local copper line can be lossy (local static,
someone running xDSL at the 5ESS, etc :wink:

2: The internet is both lossy in areas, as well as latent.

3: The 576 MTU aligns itself well with regard to
fragmentation.

So, with 576 MTU's we lose less data when there is an error,
we recover
quicker when there is one, and we fragment less.

The longer the packet, the longer the transmission time. The
longer
the transmission time, the longer for "recovery".
(Two way handshake thing)
Don't underestimate the transmission latency
of a (1500) packet at 9600/14400/28800 baud....

Smaller MTU's are (based on some earlier work) slower to get
massive data out the pipe, but better when interactivity is
desired,
and network errors are present.

(It should also handle *oversubscription* states better, as
well,
for about the same reasons...)

My two cents....

   I am sure everyone will give me change......

:slight_smile:

Darrell Fuhriman wrote:

10

I just had an interesting thought...

Has anyone done an analysis of how having a smaller MTU affects
slow-start? It seems to me that a TCP session would come up to speed
about 3 times faster with a mtu of ~500 vs a mtu of ~1500.

BTW, I can confirm that a MTU of ~500 does seem to make problems related
to Flow control problems and noisy line conditions almost go away. We
tend to not tell our users about the smaller mtu setting, though, but
instead help them to fix their CTS/RTS or line problem.

- Forrest W. Christian (forrestc@imach.com)