connlib: remove refreshing of MTU about firezone HOT 6 CLOSED

Yeah, the performance gain from increasing MTU is marginal, but the potential hard-to-debug and diagnose issues are large.

The only case I can think of where MTU might make a difference is #4129 but we should make sure the MTU is not the problem there.

from firezone.

Yeah, the performance gain from increasing MTU is marginal, but the potential hard-to-debug and diagnose issues are large.

I am not this is true. The performance gains from an increased MTU can be quite large. This is why cloud providers use jumbo frames in their backbone (MTU 9000).

However, in order to achieve that, we would need to deploy a path MTU discovery algorithm (QUIC has one) do figure out what the largest MTU is we can use on the nominated candidate pair. Once we have discovered that, we can manually set the MTU of our device to a larger number.

What we have today does not make any sense to me. The TUN device cannot magically discover a larger MTU, yet we have a "refresh MTU" functionality. Or am I missing something?

from firezone.

That was done IIRC in case the admin overrode the MTU that we set on the WG interface.

It may not hurt to keep it around.

The max MTU we'd ever be able to use is 1420, and probably more like 1370 safely (cloud providers eat another ~50 bytes).

At that point we are looking at a difference of about 7%. In practice the gains are negligible. We did a lot of testing with this for 0.7 and concluded with a default of 1280 because if you're wrong about that it can even break SSL.

See here for some more tests -- optimal MTU vs 1280 is about 10% difference max in the best cases

nitred/nr-wg-mtu-finder#4

from firezone.

See here for some more tests -- optimal MTU vs 1280 is about 10% difference max in the best cases

nitred/nr-wg-mtu-finder#4

None of these seem to test jumbo frames though?

If you are not doing path MTU discovery, then 1280 seems safe yes. But you can get real performance improvements out of it if you probe for a higher MTU on the network path. See https://datatracker.ietf.org/doc/html/draft-ietf-tram-stun-pmtud-15 for example.

If a customer runs both a gateway and a client on AWS for example, dynamically discovering the path MTU would allow for performance improvements there.

That was done IIRC in case the admin overrode the MTU that we set on the WG interface.

What is the usecase here? Do we really need to keep code around for this?

It may not hurt to keep it around.

Sending ioctl requests are some of the few places where we have unsafe code and it would be nice to remove as much of that as possible.

from firezone.

None of these seem to test jumbo frames though?

Do jumbo frames work across the internet? I don't think we've ever seen a use case where jumbo frames could work reliably. The interface MTU would still need to support the lowest common denominator client, right?

What is the usecase here? Do we really need to keep code around for this?

We don't know yet. One customer is reporting issues with their application that wanted to try adjusting the MTU for: #4129 we have yet to confirm if MTU is the issue.

I guess we'll know if we remove it ;-). I am OK removing it and re-adding it if we find someone that needs it.

from firezone.

None of these seem to test jumbo frames though?

Do jumbo frames work across the internet? I don't think we've ever seen a use case where jumbo frames could work reliably. The interface MTU would still need to support the lowest common denominator client, right?

Yes, I just realized that from the gateway's perspective, we are likely connected to a lot of clients so it would be the lowest MTU across all clients.

from firezone.