Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Design rationale behind allowing peers to choose MTU? #1024

Closed
turretkeeper opened this issue Mar 7, 2023 · 6 comments
Closed

Design rationale behind allowing peers to choose MTU? #1024

turretkeeper opened this issue Mar 7, 2023 · 6 comments
Labels
question Help or support needed

Comments

@turretkeeper
Copy link

From what I hear, IPv6 does not accept packets higher than the interface MTU, period. I won't pretend to know this for sure, but it sounds like allowing to choose different MTUs would be a recipe for overhead just for negotiation, if such negotiation even exists. Why does Yggdrasil not standardize it in a similar way address space is a defined standard?

@neilalexander neilalexander added the question Help or support needed label Mar 7, 2023
@neilalexander
Copy link
Member

When you send a packet to a remote node, Yggdrasil automatically exchanges the MTU as a part of the session setup and the lower of the local & remote MTU values is chosen as the effective session MTU.

If you send a packet larger than the effective session MTU, Yggdrasil generates and sends back an ICMPv6 Packet Too Big notification back to the sending application which causes the application/network stack to adjust future packet sizes down to the required size, which is the exact same mechanism by which Path MTU Discovery (PMTUD) normally works on other IPv6 networks (although normally it would be intermediate routers generating that notification instead).

Doing this means that pairs of nodes that support larger MTUs will be able to benefit from reduced overheads and increased throughput, but if you send a packet to a node that only supports smaller MTUs, Yggdrasil will do the right thing and tell userspace about the reduced MTU.

@turretkeeper
Copy link
Author

Thank you. Is there a use case where limiting the MTU past the underlying limit would pose an advantage?

@neilalexander
Copy link
Member

Because Yggdrasil’s peerings are TCP-based, we aren’t really limited by the underlying MTU at all. The TCP stream will operate at the usual underlying link MTU and we can continue to send larger packets over it, as TCP will segment them and enforce ordering automatically.

@turretkeeper
Copy link
Author

Pardon the daring question, but why not remove this as a configuration field entirely? From what you are saying, it appears to me that the value that gets set by default is one of the best options, if not the best option period.

@neilalexander
Copy link
Member

The origin of the session MTU exchange is because the maximum MTU varies between different platforms, i.e. max 65535 works on macOS/Linux/Windows, 32767 on FreeBSD, 16384 on OpenBSD. It also occasionally makes sense to be able to reduce the MTU if you are routing your /64 routed subnet down a pipe with a lesser MTU, i.e. most links.

Most of the time, users will have no reason to change this option though and the default is sane.

@turretkeeper
Copy link
Author

That makes sense, thank you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Help or support needed
Projects
None yet
Development

No branches or pull requests

2 participants