I think that adding a Stun function to QUIC is very straightforward: add a frame "i see you from this address", have peers send it in connection responses or with path responses. That goes very well with the multipath extensions.
Adding an address announce frame to Quic is also straightforward. It is also very useful in multipath operations: "you can contact me at this alternate address". After that, the missing part for ICE is the bidirectional probe. We can debate which is more complex, adding the function to Quic or coordinating ICE and Quic. -- Christian Huitema > On Jul 18, 2023, at 8:37 AM, Joerg Ott <[email protected]> wrote: > > Hi Marten, > > good writeup, thanks much; I am with Dan that the geenral direction > makes sense. (We've been looking at the interaction with ICE for RTP- > over-QUIC). > > One bit I always struggle with ICE when using it together with a > powerful transport is not the initial setup but the subsequent > operation. > > When two ICE agents negotiate some addresses (and possibly do their path > probing), they will then hand over the transport addresses to be used > for the QUIC connection. At this point, the state within ICE and the > state within QUIC agree. > > There are reasons for QUIC to update address information (take a NAT > rebinding or a preferred server address), but those won't necessarily > be propagated back to the ICE state machine, so the states start to > diverge. > > If you use ICE with plain old UDP, it'd be up to ICE to discover > changes and reconfigure address pairs, including probing. > > This doesn't have to be a issue but it may be useful to document how > ICE and QUIC are supposed to interact for error conditions and address > changes. > > Cheers, > Jörg > >> On 11.07.23 07:20, Marten Seemann 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/ >> <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 >
