Re: [Moq] Scope of MOQ and ULL Streaming

["Ali C. Begen" <[e-mail]>]

> [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. 

+1
 
> ...
> 
>> 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. 

Agreed. Doing things on the server side has pros and cons but latency is not necessarily one of the pros. 

>> 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.

If there were some performance numbers put forward by the RUSH folks, we would have a better idea. Without a code we can play with and no reported results, your conclusion is just a guess and it is not necessarily better or worse than mine.

Frankly speaking, there is a lot of commonality that we can focus on between the two protocols for now and maybe by then there will be a public/open-source implementation of RUSH to see the performance differences. 

>> 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.

Agreed and because of that we are still repeating some of the questions that were asked a year ago. It is not necessarily a bad thing and every viewpoint may provide new insights into the problem at hand, but I feel we are reinventing some of the things we had in the early days of DASH/CMAF (with very minor changes and not necessarily all good). 

As you all know, codec folks publish a new codec standard once they are about 50% better than the last one. We should debate how much we need to be better than what we have today or what we are addressing that was not addressed before. Then, we write the requirements for that purpose and list the agreed assumptions.

-acbegen