Overall this sounds like it could be useful for P2P QUIC, though the presence of multiple modes sounds like the use-cases haven't been fleshed out enough. What's the goal here?
Also, for this to work P2P, we'd need QUIC server migration since preferred address doesn't let you try a list of ICE candidates. That or pull out the multipath hammer. FWIW, Tommy Chris and Eric had written up the address signaling part up one pandemic ago: https://datatracker.ietf.org/doc/draft-pauly-quic-address-extension/ David On Tue, Jul 18, 2023 at 9:34 AM Christian Huitema <[email protected]> wrote: > 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 > > > >
