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 <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/%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