MTU probing?

[onehalf3570]

Any plans to implement Path MTU discovery?

At the moment the default value is 1280 (which is the minimum for IPv6 according to RFC8200) and setting a higher value results in this warning:
Warning: MTU is not the default 1280. This is not supported. Packet loss and other issues may occur
(

usque/cmd/socks.go

Line 163 in d0eb96e

if mtu != 1280 {

)

..yet setting it to a higher value seems to be working fine in my case (just tried 1400).

Theoretically we should strive to set the maximum possible MTU for performance reasons.
Max MTU should be lower (than the physical link MTU) by the MASQUE protocol overhead (which should probably be just IP header (20) + UDP header (8), but I didn't check), so 1472 bytes for a normal link.
(If there are other tunnels in-between, then the value would be lower)

Finding out the maximum value could only be done empirically(?). Other similar software implements this (e.g. ocserv https://gitlab.com/openconnect/ocserv/-/blob/master/src/worker-vpn.c#L1184) - any plans to do something similar?

Thanks.

[Diniboy1123]

Hey. If you check my profile, I recently released a Rust version for the nativetun mode which does PMTU discovery. usque was primarily a proof of concept/research client and I never got to implement these features myself. On my residential home internet anything over the initial hardcoded value introduced dropped pkts, so I wouldn't want to increase the defaults, but PMTU discovery sounds like a good idea.

Also, increased MTU on the tun interface never worked for me, only increasing the initial packet size had some success.

If I ever have the free time for usque again, I will definitely add this too.

Thanks for the idea!

[tollfree]

Hi guys,

For MASQUE protocol, Cloudflare recommends 1361 bytes IPv4 and 1381 bytes IPv6 for full functionality. The 1361 minimum is specifically because IPv6 inner traffic requires 1280 bytes minimum packet size + 53 bytes MASQUE encapsulation + 28 bytes IP/UDP headers.

--mtu 1419 = maximum inner MTU for standard 1500-byte Ethernet, zero fragmentation risk, I suppose.
(1500-(53+28))

My tests indicate that there is no packet loss with this value.

[Diniboy1123]

Thanks for this. That is actually very good to know. I added PMTU probing from the Rust version here too in usque v1.5.0, so if you don't specify a -i flag, it will automatically probe the max size it can still transmit.

Regarding inner MTU, the official client uses 1280 for me always. I made that the default value. But if you decide to use bigger values and it works for you fine, you are free to do so. This is exactly the point of a research client. :)

[tollfree]

I completely forget to mention that -m 1419 only works when —http2 is present. In QUIC mode, such value is not valid