Is there such a thing as a "typical" or "de facto" default for MTU size?
That's a fairly broad question.
Is 1500 common? Yes, absolutely, for traditional ethernet on a LAN.
Is it safe to assume 1500 or expect it for any connection? No. Mobile users that connect from anywhere may have different MTU's at different times.
We sometimes reduce MTU for datacenter servers that may provide services to remote offices over a VPN connection.
VPN connections in general will most likely have a reduced MTU, and those are all over the place. It could be 1410, 1390, 1362, or some other curious number.
If you are interested in the max payload size for a given tcp connection, you would probably find the negotiated Maximum Segment Size more meaningful. For a standard 1500 MTU LAN connection, that would typically be 1460, but the upshot is it should reflect the size that is acceptable to both hosts.
For connections that traverse many hops, it may be unrealistic to expect that all hops have a "standard" MTU, or that MTU can be reliably determined. See Path MTU Discovery discussions on the topic.
Path MTU Discovery
http://en.wikipedia.org/wiki/Path_MTU_discovery#Problems_with_PMTUD
Circumventing Path MTU Discovery issues with MSS Clamping
http://lartc.org/howto/lartc.cookbook.mtu-mss.html
In answer to:
- It's hard to answer this, because there is always going to be a summary of things that impact software performance when it touches the network. An MTU optimized for switchport to switchport communication won't do you much good over a WAN link or worse yet a VPN which is going to add overhead and potentially fragmentation.
- Yes, but you can't really control what's upstream in all situations!
- Yes you are overthinking it, are you really writing software thats going to reach back down into layer 2 for optimization? If you were writing say... an iSCSI driver then yes you're probably going to need to consider things like this.
You should not care about the MTU as the network stack will take care of the necessary optimizations. If you are using TCP, the stack may use methods for the calculation of the Maximum Segment Size (MSS) which in turn ideally is going to result in packets that are smaller than the lowest MTU in the path. One of them is PMTU discovery.
In general, you should not try to outsmart the stack - the layered architecture of TCP/IP employs the abstractions for good reasons. Unless you have better ones, you should leave the functionality of segmentation and fragmentation where it has been designed to be.
As others have written, there is no "safe MTU" to assume aside from the minimum defined MTU for IP packets - which is 68 bytes and thus has rather low practical value due to the enormous overhead.
Typical support issues due to MTU limitations are mainly twofold:
- unnecessary fragmentation and thus higher protocol overhead and higher latencies for ping-pong protocols
- broken transmissions due to ignorant firewall admins filtering ICMP and thus breaking PMTU discovery along the path
Both factors are nothing you should be dealing with in an application.