Re: [AVTCORE] IP address/port number handling in "RTP-in-QUIC" encapsulation layer

[Martin Thomson <[e-mail]>]

For me, this is as much a conversation about ICE as it is about QUIC.

In my imagination, QUIC over ICE works without connection IDs ... if you want it to.  You only need connection IDs at the point where you have an endpoint that wants to multiplex multiple QUIC connections on the same IP+port on its end (servers being sort of natural users of this).

In that model, you establish a QUIC connection over an ICE session and have at it.  QUIC does have an understanding of the path it flows over, but you can essentially suppress all of that. ICE is responsible for managing the details of selecting a path, establishing reachability, obtaining consent to send, and all that stuff.

If that is where you end up, the system you build with QUIC isn't too dissimilar to the current one.  Of course, there are ...properties, which might be drawbacks.  Two big ones:

 - QUIC uses path information to determine a bunch of different things and you are making it ignorant of those details.  Now you don't get a new congestion controller or RTT estimator when you change paths.  This might be good in the sense that you were really talking to the same endpoint anyway and the path properties are essentially the same; or it could be very bad in the sense that now you have a new path and you are sending at a rate that will overload that new path.

- QUIC has a nice design for maintaining privacy across these migrations, whereby it rotates the connection IDs in ways that make traffic across different paths unlinkable.  By making QUIC ignorant of path changes, you now make flows linkable.  It's quite possible (I haven't checked) that ICE already leaked that information though, so maybe that's not something you need to concern yourself with.

Alternatively, a design where you maintain awareness of different paths in QUIC is also possible.  Current implementations only handle one path at a time, but that's probably workable for most applications.  You let QUIC know about new paths and let it deal with that.  There is *some* redundancy (QUIC will validate paths that ICE already validated), but you get the opposite end of each of the above trade-offs.

In either case, maybe this is an opportunity to improve the privacy characteristics of ICE.

On Thu, May 12, 2022, at 09:35, Spencer Dawkins at IETF wrote:
> We've had some pretty interesting observations in 
> https://github.com/SpencerDawkins/sdp-rtp-quic-issues/issues/4 about 
> our observation that RTP/RTCP knows about IP addresses and  port 
> numbers, but QUIC applications only use IP addresses and port numbers 
> when establishing connections, and after that, QUIC applications are 
> using connection IDs, even if underlying IP addresses change because of 
> NAT rebinding or the QUIC implementation itself performs connection 
> migration. 
>
> This is obviously part of a larger question about RTP-in-QUIC 
> encapsulation layer functionality, but it's interesting now, because 
>  * if an encapsulation layer can handle all the vagaries of ports and 
> IP addresses, the application doesn't have to
>  * if an application is talking to a single IP address/port number, the 
> encapsulation layer can continue to present that interface to the 
> application, no matter what else happens below the encapsulation layer.
>  * If the IP address/port numbers are "virtual", the underlying IP 
> addresses need not even be the same IP address family. If an 
> application thinks it's talking to an IPv4 endpoint even if the 
> underlying network supports IPv6, this could remove some impediments to 
> IPv6 migration. 
>  * If the QUIC connection ID is the same for all the m=lines, this 
> might provide bundling functionality as well. 
> Obviously, this will require more thought (Suhas suggested "design 
> session" in one of the comments), but does it seem interesting and/or 
> useful?
>
> Best,
>
> Spencer
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt