PC Bozo's World bites again (CNN, too)
rirving at onecall.net
Thu May 28 22:30:13 UTC 1998
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
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
It was working in 128 byte packets... This incurred an
overhead... So we came out with X-modem-CRC, and then
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
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
probability of hitting a mux. (Which may result in mulching)
The longer the haul, the higher the probability a packet had
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
1: Your local copper line can be lossy (local static,
someone running xDSL at the 5ESS, etc ;)
2: The internet is both lossy in areas, as well as latent.
3: The 576 MTU aligns itself well with regard to
So, with 576 MTU's we lose less data when there is an error,
quicker when there is one, and we fragment less.
The longer the packet, the longer the transmission time. The
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
and network errors are present.
(It should also handle *oversubscription* states better, as
for about the same reasons...)
My two cents....
I am sure everyone will give me change......
Darrell Fuhriman wrote:
> Michael Dillon <michael at 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/%7Enetpro/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.
More information about the NANOG