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 <tasveren@rbbn.com> 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 <avt-bounces@ietf.org> *On Behalf Of * Colin Perkins
> *Sent:* Thursday, May 12, 2022 8:08 AM
> *To:* Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
> *Cc:* IETF AVTCore WG <avt@ietf.org>
> *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 <
> spencerdawkins.ietf@gmail.com> 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
> avt@ietf.org
>
> 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
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt
>