Overall this design seems reasonable to me. Do you have an application/deployment in mind that would benefit from it? Google tried rebuilding WebRTC over QUIC some number of years back but it ended up being quite a lot of work compared to the benefits over the existing stack, so the project was canceled. It would be great to have a killer app for this technology.
One minor note: draft-seemann-quic-address-discovery should acknowledge the prior art in draft-pauly-quic-address-extension. Not that this part is rocket science, but it's always nice to point out previous work. David On Tue, Oct 29, 2024 at 11:59 AM Christian Huitema <huit...@huitema.net> wrote: > Yes, the "path challenge" packets are usually padded to perform address > validation and MTU validation in a single transaction. As you say, > sending a lot of fully padded packets may create some overhead. It may > also create a "request forgery" concern, as stated in the security section. > > Basically, we have a tradeoff. RFC 9000 does not actually mandate > padding of path challenge packets. In particular, servers are always > required to apply anti-amplification protection. If anti protection > limits the size of the server packets, they can defer PMTU validation > until more data has been received from the client, or until the client's > address has been validated. Sending unpadded path challenge packets is > not a protocol violation, it is just a less efficient, because it > inserts a 1RTT delay. > > The downside is using the "masque" path for an extra 1-RTT. The upside > is lower overhead from failed trials, and also lower "amplification" > concerns -- basically, having the same impact as ICE currently does. > Opinions may differ, and it would be nice to hear them. > > -- Christian Huitema > > On 10/29/2024 5:47 AM, Ben Schwartz wrote: > > 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 > > > > > > > > -- > Masque mailing list -- mas...@ietf.org > To unsubscribe send an email to masque-le...@ietf.org >
