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

["Asveren, Tolga" <[e-mail]>]

  *   I didn’t mean “ordered delivery” and presume what is being looked is “RTP over unordered QUIC stream”
  *   I wouldn’t think that restricting use of “RTP over QUIC” to WebRTC -or even Web* in general- should be the target
     *   It is just yet another transport protocol for RTP
     *   Various deployments models/equipment could use it
     *   In that sense, ICE also shouldn’t be assumed
  *   Server connection migration is again related with the above argument: I don’t think the use case should be restricted
     *   It really would help greatly to solve some practical issues and would make high-availability much easier to get right/possible for certain deployment models
     *   Ideally this should be supported by QUIC itself, rather than as a “SDP workaround”
        *   Some folks in this group may have more insight about the anticipated fate of “QUIC server migration support” and it would be really useful if they share it

Thanks,
Tolga
From: Bernard Aboba <[e-mail]>
Sent: Sunday, May 15, 2022 8:23 PM
To: Asveren, Tolga <[e-mail]>
Cc: Colin Perkins <[e-mail]>; Spencer Dawkins at IETF <[e-mail]>; IETF AVTCore WG <[e-mail]>
Subject: Re: [AVTCORE] [EXTERNAL] Re: IP address/port number handling in "RTP-in-QUIC" encapsulation layer

Comments below:

  *   Ability to use a single QUIC connection for multiple RTP streams sounds reasonable

     *   There is no need to deal with transport layer issues, e.g. NAT traversal for each of them separately
     *   Provides implicit bundling
     *   Each RTP stream would map to a QUIC stream

        *   This needs to be signaled in SDP
[BA] Why does RTP need to be transmitted over a reliable QUIC stream?  Can't RTP packets be transported in QUIC datagrams (no associated stream)?   Even if an RTP stream is transmitted over a reliable stream, why does the mapping of RTP streams to a specific QUIC stream need to be signaled?  APIs such as WebTransport don't provide QUIC stream IDs, if only because of HTTP proxies which can scrambled them, so such signaling might not be possible or useful.

If the QUIC connection is viewed as a generalized transport by which (multiple) RTP/RTCP streams are transported, to be de-multiplexed at the receiver, might it not be possible for a single RTP stream be transmitted over a combination of multiple streams and datagrams (e.g. base layer over a single reliable stream, upper layers on datagrams or frame/stream)?
Not saying this is desirable necessarily, but wondering why it is inherently impossible.


     *   OTOH, this would cause all RTP streams to be treated the same from network perspective, e.g. prioritization

Why do all RTP streams (or portions of RTP streams) need to be treated the same?  In SVC, it seems to me like it might be desirable to use differential reliability (e.g. higher reliability for the base layer than upper layers).


  *   TCP fallback

     *   QUIC may fallback to using TCP

[BA] In WebTransport, an HTTP/3 connection can fallback to HTTP/2. Note that this need not be automatic (e.g. the application could choose to handle the failure to establish an HTTP/3 connection in another manner).

     *   I presume it would be up to the application to detect that, tear down the RTP session and create a new one with UDP
     *   [BA] Presumably, a failure to establish a QUIC session would indicate that UDP transport is not possible, so "creating a new one with UDP" wouldn't be likely to succeed either.

  *   Connection migration

     *   Currently, QUIC support connection migration only for the client
     *   [BA] Why would QUIC connection migration be needed for P2P QUIC, when that is handled by ICE? In WebRTC data channel, connection migration is explicitly forbidden, because it was not needed.
     *   There are requests/proposals to allow server connection migration as well but I am not sure when -if at all- those would make their way into QUIC
     *   [BA] Again, why would this be needed for P2P QUIC?

On Sun, May 15, 2022 at 12:43 PM Asveren, Tolga <[e-mail]<mailto:[e-mail]>> wrote:
A few thoughts:

  *   Ability to use a single QUIC connection for multiple RTP streams sounds reasonable

     *   There is no need to deal with transport layer issues, e.g. NAT traversal for each of them separately
     *   Provides implicit bundling
     *   Each RTP stream would map to a QUIC stream

        *   This needs to be signaled in SDP

     *   OTOH, this would cause all RTP streams to be treated the same from network perspective, e.g. prioritization

  *   TCP fallback

     *   QUIC may fallback to using TCP
     *   I presume it would be up to the application to detect that, tear down the RTP session and create a new one with UDP

  *   Connection migration

     *   Currently, QUIC suppor5t connection migration only for the client
     *   There are requests/proposals to allow server connection migration as well but I am not sure when -if at all- those would make their way into QUIC
     *   Supporting use of separate QUIC connections in a unidirectional way for a single RTP stream could be useful

  *   Using an already established QUIC connection for RTP sessions

     *   For example, the QUIC connection which was established for signaling
     *   Motivation/drawback would be similar to the first point above

Thanks,
Tolga
From: avt <[e-mail]<mailto:[e-mail]>> On Behalf Of Colin Perkins
Sent: Thursday, May 12, 2022 8:08 AM
To: Spencer Dawkins at IETF <[e-mail]<mailto:[e-mail]>>
Cc: IETF AVTCore WG <[e-mail]<mailto:[e-mail]>>
Subject: [EXTERNAL] Re: [AVTCORE] IP address/port number handling in "RTP-in-QUIC" encapsulation layer

Hi,

I’d argue that RTP doesn’t care about IP addresses and ports; it just needs a way of separating out traffic intended for different sessions. The signalling cares.

Colin



On 12 May 2022, at 00:35, Spencer Dawkins at IETF <[e-mail]<mailto:[e-mail]>> wrote:

We've had some pretty interesting observations in https://github.com/SpencerDawkins/sdp-rtp-quic-issues/issues/4<https://clicktime.symantec.com/39XKnot2mRQ7buAdFxJ5MBH6Gi?u=https%3A%2F%2Fgithub.com%2FSpencerDawkins%2Fsdp-rtp-quic-issues%2Fissues%2F4> 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]<mailto:[e-mail]>
https://clicktime.symantec.com/39YMrvS54gYMD12Y92fhSpQ6Gi?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Favt


Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.
_______________________________________________
Audio/Video Transport Core Maintenance
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/avt<https://clicktime.symantec.com/3HG6Rp2mS7cp9rqjgnXFoac6H4?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Favt>

Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.