ECSTech <> wrote:
> What a lifesaver you are!. the "You can do this with DrTCP from
> http://www.broadbandreports.com/drtcp" worked just fine setting the
> MTU to 1492.
>
> That's so strange. Why is MTU set by default to 1500 if it doesn't
> work?
A complete explanation would fill a university lecture. But ...
1500 bytes max data per packet is the default for ethernet connections, and
as far as your Windows is concerned it is talking to an ethernet, whether a
wired one, or a wireless link pretending to be an ethernet. 1500 would work
just fine within your LAN, not touching the DSL link.
But data packets on the DSL link between your router and your ISP are
encapsulated in another protocol which steals 8 bytes from each available
packet, leaving only 1492 for your data. Had your Windows PC been connected
directly to a plain DSL modem (rather than a DSL modem + router), then
Windows would do the encapsulation itself (as part of the DSL pseudo
dial-up), and would know about only having 1492 bytes per packet, and behave
accordingly.
But your Windows is connected to a router, and the encapsulation is being
done inside the router, so Windows has no way of knowing about it, and it
assumes the default 1500 for ethernet. The effect of sending a too-long
packet is either (a) that your router drops the packet on the floor and
normally sends back an ICMP packet warning the sender that at least one
packet was too long, or (b) the router arbitrarily splits the packet into
two (which causes poor performance over DSL). Windows has a recovery
mechanism and is supposed to back off and retry with smaller packet sizes
(MTU), until they start working. Various things can go wrong with this.
Some users have ultra-paranoid firewall settings, and thus block the
returning ICMP packet that was meant to help Windows reduce the MTU
promptly. If the transmission was encrypted (https), then the MTU discovery
by Windows is likely to have generated so many retries that the stream
cannot be unencrypted successfully, or the arbitrary splitting of packets
into two can invalidate the security checks.
Most of the time, Windows can auto-discover the MaxMTU and recover (though
maybe with a considerable performance penalty). Sometimes, the MTU
discovery algorithms fail, as in your case. So telling Windows in advance
only to use 1492 bytes per packet means that everything works first time,
the DSL link is used at maximum efficiency, and there is no performance
penalty associated with splitting packets into two.
If that sounded confusing, it's because I am trying to summarise something
complicated too much for easy reading.
Cable users need not worry about this: cable normally uses MaxMTU 1500.
--
Robin Walker [MVP Networking]