North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

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

  • From: Richard Irving
  • Date: Thu May 28 18:45:14 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
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 ;)

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......

:)




Darrell Fuhriman wrote:
> 
> Michael Dillon <[email protected]> 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.
> 
> Darrell