General direction makes sense. One thing, though: the direct path may — or may not — improve performance for the end user or for the end user's application, depending on the loss/latency/bandwidth/jitter of the two paths and the needs of the application. For example transferring a file over a proxied connection could be better (higher bandwidth) than a direct connection which is being rate-limited by the path characteristics. Considering multipath QUIC, I would try to keep both paths up and running at least while multipath QUIC itself determines which path is better for that application's needs — which might be 'both paths, simultaneously', too!
-d > On Jul 10, 2023, at 10:20 PM, Marten Seemann <[email protected]> wrote: > > I just submitted a new draft that describes how to do NAT traversal using > QUIC: > https://datatracker.ietf.org/doc/draft-seemann-quic-nat-traversal/ > > The document defines 3 distinct modes. The first mode is the simplest one, > first running ICE to completion to find a suitable path between two nodes, > and then establishing a QUIC connection on that path. > The other two modes use a proxied QUIC connection to do the ICE signaling > (potentially using one of the protocols defined by the MASQUE WG), and then > make use of QUIC connection migration to migrate to a better / direct path. > > This is an early draft version, and I wouldn’t be surprised if it wasn’t > actually implementable, most likely due to my limited familiarity with ICE. > I’d appreciate feedback if the general direction makes sense. > > Cheers, > Marten
