Fine-tune the MTU discovery multiplier for the maxmtu < MTU case.
authorEtienne Dechamps <etienne@edechamps.fr>
Wed, 31 Dec 2014 16:21:08 +0000 (16:21 +0000)
committerEtienne Dechamps <etienne@edechamps.fr>
Fri, 2 Jan 2015 09:55:54 +0000 (09:55 +0000)
commitf89319f9815da5ece8e96f1a2a777fb6d2e31c33
tree0521ac7cbad45271101529f47971808ff0a266f1
parentbce17c83e871cb8a8c9158045eaf13f1be4b3d13
Fine-tune the MTU discovery multiplier for the maxmtu < MTU case.

The original multiplier constant for the MTU discovery algorithm, 0.97,
assumes a somewhat pessmistic scenario where we don't get any help from
the OS - i.e. maxmtu never changes. This can happen if IP_MTU is not
usable and the OS doesn't reject overly large packets.

However, in most systems the OS will, in fact, contribute to the MTU
discovery process. In these situations, an actual MTU equal to maxmtu
is quite likely (as opposed to the maxmtu = 1518 case where that is
highly unlikely, unless the physical network supports jumbo frames).
It therefore makes sense to use a multiplier of 1 - that will make the
first probe length equal to maxmtu.

The best results are obtained if the OS supports the getsockopt(IP_MTU)
call, and its result is accurate. In that case, tinc will typically fix
the MTU after one single probe(!), like so:

    Using system-provided maximum tinc MTU for foobar (1.2.3.4 port 655): 1442
    Sending UDP probe length 1442 to foobar (1.2.3.4 port 655)
    Got type 2 UDP probe reply 1442 from foobar (1.2.3.4 port 655)
    Fixing MTU of foobar (1.2.3.4 port 655) to 1442 after 1 probes
src/net_packet.c