Subject: [AVTCORE] Mapping RTP onto QUIC

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 15 Sep 2020 10:41:46 -0500

Dear AVTCORE,

As part of the set of ideas included in the IETF 107 RIPT BOF [1] there was
a proposal [2] to use HTTP/3 for media {"when it is available, falling back
to media byways when it is not").

As best I can decode from the discussion during the RIPT BOF [3], and
subsequent non-chartering, the RIPT BOF participants didn't support moving
forward, but we didn't really converge in those discussions on whether we
should be looking at HTTP/3 for media, or a more conservative mapping of
RTP directly onto QUIC transport.

I know there have been proposals for an RTP mapping onto QUIC (most notably
[4]). Are some people in AVTCORE interested in pursuing that
alternative, now that QUICv1 is banging around in WGLC?

Best,

Spencer, sending this e-mail to AVTCORE at the suggestion of the ART and
TSV ADs

[1} https://datatracker.ietf.org/group/ript/meetings/
[2]
https://tools.ietf.org/html/draft-rosenbergjennings-dispatch-ript-00#section-8.8
[3] https://www.ietf.org/proceedings/107/minutes/minutes-107-ript-00
[4] https://tools.ietf.org/html/draft-rtpfolks-quic-rtp-over-quic-01

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 15 Sep 2020 10:37:36 -0700

Spencer said:

"As best I can decode from the discussion during the RIPT BOF [3], and
subsequent non-chartering, the RIPT BOF participants didn't support moving
forward,"

[BA] The Automatic SIP trunking and Peering (ASAP) WG was subsequently
chartered:
https://datatracker.ietf.org/wg/asap/about/

but the charter seems to omit the media aspects that were discussed during
the RIPT BOF.

The HTTP/3 datagram draft (
https://tools.ietf.org/html/draft-schinazi-quic-h3-datagram) (which played
a part in some of the scenarios described in the RIPT BOF) isn't currently
a WG work item anywhere, although
https://tools.ietf.org/html/draft-ietf-quic-datagram did get adopted by the
QUIC WG.

"but we didn't really converge in those discussions on whether we should be
looking at HTTP/3 for media, or a more conservative mapping of RTP directly
onto QUIC transport."

[BA]  I would agree that those discussions (and subsequent ones) have not
converged.  There are multiple dimensions to the non-convergence.  One axis
is HTTP/3 transport versus direct QUIC transport.   Another dimension is
how HTTP/3 would be used.  The RIPT BOF suggested a general goal of
enabling media to leverage conventional Web infrastructure; one of the
slides showed an HTTP/3 request (with a byte range!) soliciting a response
of HTTP/3 datagrams.  That is quite different from the model used in
WebTransport (either Http3Transport or QuicTransport).

Yet another dimension is what kind of media would be transported over
HTTP/3. This can include conventional streaming media (e.g. DASH or HLS
over HTTP/3), low-latency streaming media (e.g. SRT over HTTP/3), or
realtime media.

In the W3C WebTransport WG (recently formed, see:
https://w3c.github.io/webtransport-charter/charter.html ) there is now a
work item for use cases. So perhaps some greater understanding will come
out of that.
<https://datatracker.ietf.org/wg/asap/about/>

On Tue, Sep 15, 2020 at 8:42 AM Spencer Dawkins at IETF <
[email-masked]> wrote:

> Dear AVTCORE,
>
> As part of the set of ideas included in the IETF 107 RIPT BOF [1] there
> was a proposal [2] to use HTTP/3 for media {"when it is available, falling
> back to media byways when it is not").
>
> I know there have been proposals for an RTP mapping onto QUIC (most
> notably [4]). Are some people in AVTCORE interested in pursuing that
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 17 Sep 2020 08:29:48 -0500

Hi, Bernard,

> subsequent non-chartering, the RIPT BOF participants didn't support moving

Thanks for the clue here. I'd forgotten about ASAP(^), but my focus really
is on the media.

> https://tools.ietf.org/html/draft-schinazi-quic-h3-datagram) (which
> played a part in some of the scenarios described in the RIPT BOF) isn't
> currently a WG work item anywhere, although
> https://tools.ietf.org/html/draft-ietf-quic-datagram did get adopted by
> the QUIC WG.
>
> "but we didn't really converge in those discussions on whether we should
> be looking at HTTP/3 for media, or a more conservative mapping of RTP
> directly onto QUIC transport."
>

Yeah, we're definitely experimenting with both. I'd like to talk to anyone
else who is also experimenting (and can talk about it).

> work item for use cases. So perhaps some greater understanding will come

Thanks for the pointer. I was waiting for the final formation in W3C. I'll
keep an eye on that.

Best,

Spencer

* It was easier for me to keep track of BOFs that changed names when they
were chartered when I was balloting on WG charters, but I'm not complaining
that's ended!

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 17 Sep 2020 07:32:41 -0700

Spencer said:

"I'd like to talk to anyone else who is also experimenting (and can talk
about it)."

[BA] Experimentation has only become possible very recently, with the
Origin Trials of QuicTransport and WebCodecs (both of which are in Chromium
M86).  So IETF 109 Hackathon might be a place to bring experimenters
together.

Using the Trial tools, it should be possible to experiment with low-latency
streaming or realtime media over QuicTransport.  For example, it should be
possible to implement video upload by obtaining a codec bitstream using
WebCodecs, packetizing it using WebAssembly and then sending it using QUIC
datagrams or streams.

Playing with the technology might be helpful to understand its
architectural or performance limitations. For example, there are extra
memory copies in the Web architecture that typically aren't present in RTP
implementations.  For example, while there are zero-copy implementations of
QUIC, for security reasons there is an extra copy on receive or send within
QuicTransport in the browser; a copy when moving between Javascript and
WebAssembly; a copy when moving data to a Web Worker; a copy on capture; a
copy on rasterization (zero-copy rasterization tends to be unstable in the
browser), etc.

On Thu, Sep 17, 2020 at 6:30 AM Spencer Dawkins at IETF <
[email-masked]> wrote:

>> but the charter seems to omit the media aspects that were discussed
>> during the RIPT BOF.
>>