Date: Wed, 4 Feb 1998 10:51:44 -0700 (MST)
From: "Forrest W. Christian" <forrestc@iMach.com>
To: "Perry E. Metzger" <perry@piermont.com>
cc: Peter Ford <peterf@microsoft.com>, "'nanog@merit.edu'"
<nanog@merit.edu>
Subject: Re: MTU of the Internet?
Now it's been a while since I looked at latency vs transfer rates, so
maybe someone who works on this on an everyday basis would like to comment
on what ~200 more ms of latency on a 28.8 link would do to throughput
end-to-end across the net (totals of something like 350 and 512 ms
end-to-end).
We recommend that clients who care about interactive response use small
MTUs, and clients who care about download speed use higher MTUs.
It seems most of them agree that smaller MTUs improve their interactive
response for things like telnet, IRC, MUD, etc., particularly if they
are downloading/surfing at the same time.
Thx,
dennis
There's an extremely annoying potential gotcha in having clients set
lower MTUs. At least one release of Netscape's web server set the
Don't Fragment bit. In the few cases we've seen, if there was not a
1500 MTU pipe between server and client, the server could be reached,
but no HTML would be downloaded. Usually it's easier to work around
the problem on the client end than convince the server admins they
might want change things on their end.
Erm... I think you are getting a few things a bit confused here.
First, I _really_ doubt the web server set the DF bit. It is almost
certainly the OS, probably trying to do path MTU discovery.
If there is a smaller MTU in the middle, and someone is filtering ICMP
can't fragment errors then yes, you will have trouble with PTMU discovery.
The fix is to not blindly filter ICMP. Increasing the client MTU won't
fix this.
If the client lowers their MTU, there is no problem because then they
advertise an appropriate MSS and no stack should try sending packets that
it knows will need to be fragmented given the client MSS.