Is there such a thing as a "typical" or "de facto" default for MTU size?

Question

1. When writing networking software, is there a default, typical, or otherwise de facto standard for MTU size, of which I should be aware? If so, what is it?

2. Is an MTU size of 1500 (as suggested here: What is the Maximum MTU supported in DSL Standards) a good rule of thumb?

3. Also, am I over thinking this problem? Is this one of those things people think is important when writing networking software, but in practical, real-world terms, doesn't wind up mattering much since TCP will take care of the details for you?

I ask here, rather than on StackOverflow, because I want the sysadmin point of view when it comes to actual support issues related to MTU size.

UPDATE: based on some of the feedback, and initial answers, I'm narrowing the focus a bit:

• The application I'm writing will communicate between desktops/servers over a WAN connection
• It's typical desktop/server (i.e. not mobile) software, and while it's possible that a tethered laptop will use this software over a mobile network, I'm not concerned with that
• It won't even attempt to deal with any layer of the TCP stack, other than the application layer, for optimization
• VPN overhead can be ruled out for the scope of this question

Answer 1

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

Answer 2

In answer to:

1. 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.
2. Yes, but you can't really control what's upstream in all situations!
3. 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.

Answer 3

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.

Answer 4

Stick to the requirements of the protocol, and assume you can pass the data easily. However, try to avoid using fixed length blocks just over the MTU or a small multiple of it.

1. Default MTU is 1500 which is the maximum value usable on the Internet. Smaller values may be required when tunneling traffic. Most traffic will be fragmented and reassembled it it exceeds the maximum available MTU on the link. Only if the DNF (Do Not Fragment) option is set must the packets be less than or equal to the MTU. The local MTU sets an upper limit for the usable MTU.
2. As most hosts have an MTU of 1500. It is a good default value to use. Some ISPs provide links using tunneling protocols like PPPOE which provide a smaller MTU. Likewise many IPv6 early adopters may be using a tunnel and may have a smaller MTU.
3. You are most likely over thinking the problem. In the real world, you can't rely on the local MTU to determine the link's MTU. Nor can you count on it being a static value. If required packets will be fragmented and reassembled. For example block size for NFS is typically 4096, and are usually sent in fragments.