Re: [Moq] Scope of MOQ and ULL Streaming

[Bernard Aboba <[e-mail]>]

Thank you very much, for asking these questions, Luke.  Comments below.

> I also have a mostly HLS background. It's important to take a step back and explore why we want to replace HLS/DASH, and what we lose by doing so.

[BA] Perhaps rather than asking “why we want to replace HLS/DASH” we should first ask “Is it possible to extend HLS/DASH to achieve the same goals?”. 

> The best part about HLS/DASH is the HTTP ecosystem. That includes CDN support, optimized software, and general interoperability. We lose a lot of this by creating a custom pub/sub mechanism.

[BA] Yes, and it also implies that MoQ has to be a *lot* better than HLS/DASH to overcome it.  If HLS/DASH can be modified to achieve the same results (or even close to the same results) then MoQ will be DOA. 

BTW, I should add that these concerns do *not* apply to ingestion (e.g. RUSH). To my mind, RUSH is clearly differentiated from existing ingestion protocols (RTMP, SRT, RIST) and could have a decent chance of adoption if the the MoQ could produce a standard in an expeditious manner (ideally <1 year).  Since I don’t buy the argument that RUSH and WARP need to share a protocol (only a format), it seems to me that the forced mating of RUSH and WARP isn’t necessary.

> The worst part about HLS/DASH is the latency. This is caused by head-of-line blocking (buffering) and the client being in charge (requesting playlists and segments).

[BA] HoL blocking can be overcome using HTTP/3.   And it isn’t clear to me that the client being in charge necessarily implies high latency. 

> The Warp draft tackles these problems with QUIC prioritization (delivery order) and WebTransport push respectively.

[BA] It isn’t clear to me why WARP with GoP/stream WebTransport has an inherent advantage over HTTP/3 using GoP/stream transport.  It’s QUIC underneath in both cases. 

That said, one could argue that RUSH’s frame/stream transport *does* have an advantage.  That is one of RUSH’s unique differentiators compared with RTMP, for example.

> The premise behind specifying a generic pub/sub protocol is that we can support non-media applications, so it's then more attractive for a CDN to support MoQ. However I'm terrified that we don't have any other applications in mind, and we're too eager to sacrifice media functionality in the pursuit of a bigger pie.

[BA] To have a shot at wide deployment, MoQ needs a “killer application” that can’t be delivered nearly as well by modifying HLS or DASH.  The requirements document doesn’t really focus on what that is, nor does it fully enumerate all the requirements MoQ would need to satisfy to fully differentiate itself in that usage.