Hi Marten, I did a little thinking about this problem a fair while back, see https://datatracker.ietf.org/doc/html/draft-thomson-rtcweb-ice-dtls-00
That's closer in truth to your mode 3. That is, it collapses the protocols. And of course there are properties of DTLS that ensure that this is less than ideal, whereas QUIC might be better suited to the sorts of tweaks that connectivity checking demands. In particular, it is worth thinking about carefully here is how much QUIC's path validation logic is duplicative of parts of ICE and whether that is overhead that can be saved. As for the non-collapsed versions, you might need to be clearer about which part of the stack is responsible for path selection. In mode 1, this is not particularly clear. If you think of classic ICE, you essentially have ICE being responsible for path selection (especially with the continuous ICE versions) and the flow that you initiate on top of it is ignorant of path changes. That will interact somewhat poorly with a protocol like QUIC that expects to be more involved in that process. It's worse in mode 2, which might be quite confusing with the two layers interacting as they do. That could stand to be made much clearer. Cheers, theonewithan"i" On Mon, Jul 10, 2023, at 22: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/ > > 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
