Subject: [AVTCORE] QUIC RTP Tunnelling

From: Samuel Hurst <[email-masked]>
Date: Mon, 2 Nov 2020 15:05:16 +0000

Hello,

Apologies if this is not the correct forum for publicising this, but I
saw from the mailing list archive that there has been previous
discussion about mapping RTP over QUIC on this list.

I recently published an I-D that discusses multiplexing RTP sessions
over a single QUIC Transport connection, a technique I'm calling QUIC
RTP Tunnelling or "QRT". This uses QUIC DATAGRAM frames to carry RTP and
RTCP packets, with a custom flow identifier for multiplexing.

The primary motivation behind the draft is to support live video
contribution for media productions, but I see that it could have much
wider-reaching applicability than that. I invite any review comments on
the draft.

https://tools.ietf.org/html/draft-hurst-quic-rtp-tunnelling-00

Best Regards,
Sam

-- 
(he/him)
Project R&D Engineer
BCS Internet Distribution
BBC Research and Development
5th Floor Dock House, MediaCityUK

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 2 Nov 2020 07:29:07 -0800

A comment on the allocation of QUIC datagram flow identifiers. In pooled transports such as HTTP/3 over QUIC, the datagram flow identifier is used to route datagrams to a particular application, and an additional identifier is provided by the application to identify a particular flow. Therefore in a pooled transport the application will not have the ability to allocate its own application flow identifiers.

https://tools.ietf.org/html/draft-schinazi-quic-h3-datagram-05 Section 3 says:

Even flow identifiers are client-initiated, while odd flow
   identifiers are server-initiated.  This means that an HTTP/3 client
   implementation of the flow identifier allocation service MUST only
   provide even identifiers, while a server implementation MUST only
   provide odd identifiers.  Note that, once allocated, any flow
   identifier can be used by both client and server - only allocation
   carries separate namespaces to avoid requiring synchronization.

> On Nov 2, 2020, at 07:05, Samuel Hurst <[email-masked]> wrote:
> 
> Hello,
> 
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

---

From: Samuel Hurst <[email-masked]>
Date: Mon, 2 Nov 2020 16:39:24 +0000

Hello Bernard,

On 02/11/2020 15:29, Bernard Aboba wrote:
> A comment on the allocation of QUIC datagram flow identifiers. In pooled
> transports such as HTTP/3 over QUIC, the datagram flow identifier is
> used to route datagrams to a particular application, and an additional
> identifier is provided by the application to identify a particular flow.
> Therefore in a pooled transport the application will not have the
> ability to allocate its own application flow identifiers.

In order to keep the initial draft more concise, I've written it as if
the only thing that goes over the QRT session is just RTP, so I can
avoid having to specify managing different applications contending for
the same space.

However, I fully realise that in the future the draft will absolutely
have to support co-located application packet flows. I can forsee this
causing issues with things like SDP which advertise the flow identifiers
up front, but that's why I made it an optional component of the draft.

I'm keeping an eye on the development of such ideas in the DATAGRAM and
H3 DATAGRAM spaces to see what the consensus ends up being, and then I
can adopt that.

-Sam