Look at effect of increasing MTU of the TUN interface

[LeeSmet]

Currently MTU is a static 1400 to make sure packets would fit in a single packet of the lower layer. However since we use TCP and Quic, this is not strictly needed since those protocols take care of breaking up packets internally, and we also have a framing protocol for all traffic. As such, we could consider increasing the MTU of the TUN here, with the caveat that future transport implementations (if any), need to be able to handle packets larger than the actual link MTU. We should verify if this allows a significant improvement in performance. If not, we need to consider if the future hassle is worth it to do this.

[delandtj]

It actually is : IIRC, zeotier MTU was set at 2800.
basically it all boils down to this: if routed packets come to the tun iface at 1500, they will be fragmented in 2 packets, as all data needs to be encapsulated.
So: if we just set it at a 'big enough' value, the pakets originating from the node itself will be bigger , packets that come in from an IP in the routed subnet will be reassembled into the new MTU during forwarding (L3), but I need to confirm that. Path MTU discovery (pmtu) is there for a reason. Don't know if we can disable the bit by default in a tun iface

Arf: weekeepeedia knows : https://en.wikipedia.org/wiki/Path_MTU_Discovery but then I assume we need to enable that icmp message
2800 ? LGTM

[delandtj]

Looking at it, even Ygg sets it at 0xffffff O_o

[LeeSmet]

The current performance is largely sufficient for the common use case. Additionally, I'd like to keep the MTU of 1400, in case we end up setting up something like UDP transports in #144 . The currently preferred route to continue here would be #141