Re: [Moq] Charter adjustment

[Bernard Aboba <[e-mail]>]

Christian said:

"If you want low latency, you need to support datagrams, and have some way
to fragment long frames over series of datagrams."

[BA] That would provide differentiation from protocols running over
reliable streams, such as LL-HLS & HESP.

However, if you're transporting frames over QUIC datagrams and don't care
about DRM, you  might as well save CPU cycles and decrease decode latency
by avoiding CMAF containerization (e.g. use WebCodecs instead of
low-latency MSE in the player).  For E2E security, SPacket (for datagrams)
or SFrame (for frame/stream) should do the job.

"But then, if you require reassembly of fragmented frames at each step in
the relaying chain, you can easily run into head-of-line blocking."

[BA]  Not sure I understand the use case for reassembly. We're now on our 3rd
generation of forwarding meta-data
<https://aomediacodec.github.io/av1-rtp-spec/#dependency-descriptor-rtp-header-extension>,
so the "relay" should have all the info necessary to figure out what frames
and fragments to forward to what endpoints.


 That's something we can handle in MoQ. I don't know whether HESP does that
-- the specs do not appear to be publicly available."

On Thu, Jul 21, 2022 at 7:23 PM Christian Huitema <[e-mail]>
wrote:

> On 7/21/2022 7:13 PM, Bernard Aboba wrote:
>
> Ian said:
>
> "HTTPS proxies have been around for a long time, and MoQ shares many of
> those properties."
>
> [BA] Indeed, there are proposals (such as HESP
> <https://www.hespalliance.org/>) aimed at low-latency distribution
> that run over HTTP/3 and support caching.
>
> This begs the question of "Why is MoQ better?"
>
>
> If you want low latency, you need to support datagrams, and have some way
> to fragment long frames over series of datagrams. But then, if you require
> reassembly of fragmented frames at each step in the relaying chain, you can
> easily run into head-of-line blocking. That's something we can handle in
> MoQ. I don't know whether HESP does that -- the specs do not appear to be
> publicly available.
>
> -- Christian Huitema
>