Thanks to a friendly exchange at FOSDEM '23, we were pointed to this p2p crate. This crate specifically implements NAT hole punching techniques and I believe we could draw some inspiration from them.
The idea is to prepare one's own router for the remote packets by sending low TTL packets to the remote. The problem we solve here is that if our UDP packets were to reach the NAT of the remote peer before the remote peer sent packets to us, an unfriendly NAT/router could denylist us for some time.
My proposal for a protocol optimization would be:
When the first CONNECT message reaches the remote peer, it starts sending UDP packets with a TTL of 3 to the addresses contained in the CONNECT message
When the second CONNECT message reaches the local peer, it does the same until the sync timer has fired.
Why 3? The documentation of the p2p crate says: "In practice it's usually the 1st couple (or 3) routers that do NAT while others are non-NAT."
Something that would speak against this protocol optimization is the fact that hole punching is not really sensitive to timings, it seems. At least that's what our measurement campaign suggests. I'm opening this issue to also brainstorm if we could quantify the potential of this change from the data that we have gathered.
Thanks to a friendly exchange at FOSDEM '23, we were pointed to this
p2pcrate. This crate specifically implements NAT hole punching techniques and I believe we could draw some inspiration from them.Especially the TTL approach sounds interesting. Their documentation describes a scenario where it would be beneficial here: https://docs.rs/p2p/0.5.2/p2p/#endpoint-address--port-dependent-filtering-port-restricted-cone
The idea is to prepare one's own router for the remote packets by sending low TTL packets to the remote. The problem we solve here is that if our UDP packets were to reach the NAT of the remote peer before the remote peer sent packets to us, an unfriendly NAT/router could denylist us for some time.
My proposal for a protocol optimization would be:
CONNECTmessage reaches the remote peer, it starts sending UDP packets with a TTL of 3 to the addresses contained in theCONNECTmessageCONNECTmessage reaches the local peer, it does the same until the sync timer has fired.Why 3? The documentation of the
p2pcrate says: "In practice it's usually the 1st couple (or 3) routers that do NAT while others are non-NAT."Something that would speak against this protocol optimization is the fact that hole punching is not really sensitive to timings, it seems. At least that's what our measurement campaign suggests. I'm opening this issue to also brainstorm if we could quantify the potential of this change from the data that we have gathered.
cc @mxinden