[p2p-hackers] MTU in the real world

[Matthew Kaufman]

David Barrett:
> > Furthermore, I've read that if you "connect" your UDP socket to the 
> > remote side and then start sending large packets and backing off 
> > slowly, the socket layer will compute the "real"
> > MTU between two endpoints, and you can obtain it through 
> > "getsockopt".  Do you know of anyone who's tried this, and the 
> > results?

Kendy Kutzner:
> Linux:
> $ man 7 ip
> [...]
> SOCKET OPTIONS
> [...]
> 	IP_MTU 
> 		Retrieve the current known path MTU of the current
> 		socket.  Only valid when the socket has been connected.
> 		Returns an integer. Only valid as a getsockopt(2).

One must read in detail the part about what this returns for an unconnected
UDP socket (nothing useful at all), a connected UDP socket to a destination
for which Path MTU Discovery hasn't happened (the "initial estimate of the
path MTU", not to be confused with the actual Path MTU) and how the
IP_PMTU_DISCOVER option works with UDP sockets ("kernel rejects packets
(with EMSGSIZE error) that are bigger than the known path MTU if flag set").

You can, apparently, do the following, on a Linux system that supports Path
MTU Discovery: connect a UDP socket to a destination, set the socket to
IP_PMTUDISC_DO, start sending huge datagrams (that you need to know will
probably be lost), wait for EMSGSIZE errors, and watch the IP_MTU answer
(tricky, because at first it'll be the "estimate" and later it'll be the
"known"... Whether it'll ever be bigger than the "estimate" is probably
implementation-dependent and I'm not looking at the kernel sources). That's
a little more involved than simply "sending large packets and backing off
slowly". (It'd be as simple as watching the EMSGSIZE errors *if* Path MTU
Discovery were enabled by default for anything other than SOCK_STREAM, which
it is not)

The other way is to NOT connect the socket, set IP_PMTUDISC_DO, and watch
the IP_RECVERR queue for MTU updates to your destinations. Other operating
systems support some similar ways to watch for incoming errors caused by the
Path MTU Discovery process.

However, I *still* maintain that Path MTU Discovery is fraught with danger
in any environment where ICMP messages might get lost, which pretty much
includes anywhere you have real firewalls in the path, and that furthermore,
you are very unlikely to see an MTU greater than 1500 except in very
specialized environments.

Matthew Kaufman
matthew at matthew.at
www.amicima.com