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
