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

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

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]> On Behalf Of Colin Perkins
Sent: Thursday, May 12, 2022 8:08 AM
To: Spencer Dawkins at IETF <[e-mail]>
Cc: IETF AVTCore WG <[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.