Re: [AVTCORE] Registering AVP Profiles for RTP over QUIC

[Roman Shpount <[e-mail]>]

On Tue, May 17, 2022 at 12:56 AM Ross Finlayson <[e-mail]>
wrote:

> > On May 16, 2022, at 9:48 PM, Roman Shpount <[e-mail]> wrote:
> >
> > > You would end up with this encoding when RTP over QUIC is used on top
> of TCP
> >
> > What does “QUIC on top of TCP" even mean, given that QUIC is a UDP-based
> protocol?
> >
> > RTP, DTLS, and SCTP are also UDP-based protocols. They all can run over
> TCP (see  RFC 4571) when the ICE-TCP (RFC 6544) candidate is used.
>
> Yes, one could imagine RTP being sent with RFC 4571 framing over ‘QUIC
> classic’ - i.e., over QUIC as a reliable, connection-oriented protocol.
> But it would seem to make a lot more sense for ‘RTP over QUIC’ to use
> QUIC-with-datagrams.  (How likely is it that a pair of endpoints will
> support ‘QUIC classic’ without the datagram extension, but will not be able
> to communicate via TCP?)
>

I am talking about RTP over regular QUIC-with-datagrams (QUIC over UDP),
which is used for peer-to-peer connections.  When ICE is used for the p2p
connection, and when ice-tcp candidates are present, QUIC packets can be
sent over UDP or TCP with RFC 4571 framing. The flow can change during the
nomination process, and if TCP-only connectivity is allowed, RTP with
QUIC-datagrams over TCP with RFC 4571 framing can be the protocol used as a
result.


> > In any case, it seems to me that this whole discussion is begging the
> question.  First, we should come to consensus as to what problem(s) we are
> trying to solve.  Then, and only then, we can decide whether 'RTP over
> QUIC’ is an appropriate way to solve these problem(s).
> >
> > It may well turn out that 'RTP over QUIC’ is a solution in search of a
> problem.
> >
> >
> > I can see a few problems that it can solve:
> >
> > 1. Run real-time media over WebTransport
>
> Maybe.  But would this use RTP?
>

What framing would you use for real-time media? As proposed, I would even
argue that RTP-over-QUIC is not precisely RTP. It is modified to utilize
QUIC mechanisms for multiplexing, packet loss feedback, and bandwidth
estimation. Essentially, this is a discussion of the suitable framing
mechanisms to be used when real-time media is sent over QUIC.

> 2. Get rid of SCTP for data channels in the WebRTC stack
>
> OK, but this has nothing to do with RTP
>

This has something to do with multiplexing data and real-time media over a
single connection.

> 3. Replace DTLS in secure RTP channel setup by using a more modern
> protocol with cleaner implementation and faster connection establishment
> > 4. Better NAT and firewall traversal with QUIC vs. plain SRTP
>
> OK, but it seems to me that doing these (and 2.) would require
> rechartering the IETF RTCWeb Working Group to develop a new version of
> WebRTC that uses QUIC.  Perhaps this is where we should be headed (as it
> would produce a product that’s superior to the existing WebRTC, for the
> reasons you state), but this would be a big undertaking.


We can get there at some point, but providing the same functionality as
WebRTC on top WebTransport might be a better option that would not require
bringing RtcWeb Working Group back. As long as there are standardized
components that can be composed using browser API, WebRTC can be replaced
with a better performing and more flexible solution.
______________
Roman Shpount