Is there such a thing as a “typical” or “de facto” default for MTU size

mtunetworking

  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

Best Answer

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.

Related Topic