Re: [Moq] Scope of MOQ and ULL Streaming

[Luke Curley <[e-mail]>]

Hey Bernard,

On Wed, Feb 8, 2023, 1:01 PM Bernard Aboba <[e-mail]> wrote:

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

Don't forget about RTC.

The biggest problem with WebRTC is that it doesn't scale out like HLS/DASH,
arguably because it isn't compatible with the existing caching ecosystem.

The biggest problem with HLS/DASH is that it can't provide real-time
latency like WebRTC. There's definitely an opportunity to meet in the
middle, instead of two fundamentally incompatible protocols (ex. push vs
pull) based on the target latency.

The biggest problem with RTMP is that it's a dead standard. While almost
any specification is better than the current state, we do need contribution
for RTC. And while nobody is clamoring to reduce contribution latency since
there are bigger issues, I promise you it's next on my list...

I really just don't want to get caught up in an effort to standardize a
generic pub/sub mechanism that has aspirations to replace HTTP. I want to
reduce HLS/DASH latency now and I need a replacement for RTMP yesterday. We
do need to demonstrate that the protocol can be fanned out, but we don't
need to make it generic (yet).


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

I think the killer feature is being able to seamlessly switch between
participating and not. It's quite common to use a RTC protocol for
participants and a distribution protocol for the audience. However the two
are incompatible, making it burdensome to maintain and switch between both.