In previous discussions, the main challenge I've heard for this architecture is related to QUIC's approach to MTU qualification. STUN packets are tiny, so it's tolerable to send a lot of them (O(N*M) to check all candidate pairs). QUIC Initials and such are usually padded to prove that the path MTU is large enough, which makes them terribly inefficient for NAT hole punching.
How do you imagine PMTUD would work for P2P QUIC? --Ben ________________________________ From: Marten Seemann <martenseem...@gmail.com> Sent: Monday, October 28, 2024 10:42 PM To: QUIC WG <quic@ietf.org>; mas...@ietf.org <mas...@ietf.org> Subject: [Masque] p2p QUIC Hi QUIC and MASQUE enthusiasts, Christian and I have published a blog post describing our vision for a p2p extension of QUIC: https: //seemann. io/posts/2024-10-26---p2p-quic/. The idea is to do everything inside of QUIC: Imagine two p2p nodes Hi QUIC and MASQUE enthusiasts, Christian and I have published a blog post describing our vision for a p2p extension of QUIC: https://seemann.io/posts/2024-10-26---p2p-quic/<https://urldefense.com/v3/__https://seemann.io/posts/2024-10-26---p2p-quic/__;!!Bt8RZUm9aw!6W2t_dQMHs1tiFalSAENp4XfqajorAqrDd40gvq8KpYR6jDpIwBSIck716540SjXE5WUkPu96n3iZZXMysk$>. The idea is to do everything inside of QUIC: Imagine two p2p nodes first establishing a proxied connection via a relay (immediately starting to exchange application data), and the QUIC stack migrating this connection towards a direct path between the two nodes in the background. It turns out that there are just a few missing pieces: 1. We can use the listener extension to CONNECT-UDP (https://datatracker.ietf.org/doc/draft-schinazi-connect-udp-listen/<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-schinazi-connect-udp-listen/__;!!Bt8RZUm9aw!6W2t_dQMHs1tiFalSAENp4XfqajorAqrDd40gvq8KpYR6jDpIwBSIck716540SjXE5WUkPu96n3iYAYMoIo$>) to enable relaying between peers that don't have a direct connection (yet), and for peers where NAT traversal fails (thereby replacing what traditionally a TURN server would've been deployed for). 2. It is trivial to perform address discovery inside of QUIC (replacing STUN): https://datatracker.ietf.org/doc/draft-seemann-quic-address-discovery/<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-seemann-quic-address-discovery/__;!!Bt8RZUm9aw!6W2t_dQMHs1tiFalSAENp4XfqajorAqrDd40gvq8KpYR6jDpIwBSIck716540SjXE5WUkPu96n3ivL1LLoU$> 3. Finally, we can use QUIC's path migration logic to establish the NAT bindings ("hole punching") required for a direct connection between two nodes. We just need to allow the server to initiate paths, and coordinate hole punching attempts: https://datatracker.ietf.org/doc/draft-seemann-quic-nat-traversal/<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-seemann-quic-nat-traversal/__;!!Bt8RZUm9aw!6W2t_dQMHs1tiFalSAENp4XfqajorAqrDd40gvq8KpYR6jDpIwBSIck716540SjXE5WUkPu96n3i-DsCx80$> In terms of maturity, the address discovery draft has gone through a couple of revisions since we last discussed it in the QUIC WG in Prague, and is now implemented by multiple QUIC stacks. The NAT traversal draft needs a bit more work. While these drafts were all presented individually, we haven’t talked a lot about how they fit into the bigger picture before presenting the vision in our blog post. We would love to get feedback from the working groups, and help to drive the drafts to publication. -- Marten
