Re: 2 cents re: MTU

Brian Godette (bgodette@idcomm.com)
Thu, 25 Jun 1998 11:49:48 -0600


At 11:51 PM 6/24/98 -0700, Jamie Erbes wrote:
>MTU - Max transmission unit - default from windows is 1500 which
>is good for LAN but typically not so good for analog dial-up.
>The objective is to match the setting of your ISP, which is
>usually 576. You may need to call your ISP to see what their MTU
>is for your access type.

Hmmmm, so you're saying ISP's using serial *slip* links for their internal
LAN and external WAN connections to the 'net???? That'd be the only sane
technical reason for the ISP having it anything smaller than 1500, as
having it smaller just generates a technical support nightmare to configure
all their customers (dial-up and dedicated).

What amazes me is that people don't notice that all the MTU tweaking info
from so-called "experts" are all based on Win31+Trumpet Winsock+a *SLIP*
connection. And even all that was purely "well it seems to work...". It's
just like all the "the vid seems faster" comments that flew about with each
new WP ECU 2.1.* release when in fact there was no difference. It's
wishfull thinking, you expect it to be faster (being a new version, or in
this case a change to some mystical value that's not understood by most
people), so you perceive it to be faster.

The direct effects of lowering MTU size are this. Multiple TCP streams are
more responsive due to it taking less time for a packet to be received over
the link, ~160ms for 576 vs ~416ms for 1500, which is a good thing for
telnet/moo/mud. However this comes at a cost of nearly three times the
amount of packet overhead, 20 bytes for IP header and another 20 bytes for
TCP header assuming VJ header compression and only being concerned with
payload packets. So you've just introduced an additional 104 bytes every
1460 bytes of actual payload, this turns cu311.exe (10694810 bytes) into
effectively 11456632 bytes (nearly an addition 1 meg of overhead adding
another 4 minutes to the transfer for a 28.8 connect. As for effects to CU,
it'll increase CPU utilization as the OS now has to fragment the packets CU
is sending before it sends it over the link. It'll increase the likelyhood
of packet loss between you and the other end as there's now more packets
which can be dropped than before.

>RWIN - Receive window - I've seen Windows default to 8192, which,
>again, is OK for LAN but not so good for analog dial-up. A good
>rule of thumb is to set RWIN at 4X your MSS. Then round it to a
> number divisible by 32 for further optimization.
>

Hmmm, geee, I hope you do know that RWIN is what controls how much data you
can receive on a TCP stream before sending an ACK. Reducing this can
potentialy slow down a TCP transfer drasticly. Setting it larger increases
the response time for lost/corrupted packets. RWIN wants to be large enough
so that there's always slightly more payload in transit than it takes for
an ACK to reach the other end (which is where unloaded ping times become of
some interest). It takes around 420ms to receive a 1500 byte packet (1460
byte payload), as soon as the RTT of an unloaded ping goes over 840ms RWIN
needs to become 3x MTU. So yeah 4x works, but only for *analog* modem
connections, soon as you go to x2/k56flex/v.90 the rules change, the rules
change even more for ISDN/FR/xDSL/cable modem/etc.