Re: [Moq] Scope of MOQ and ULL Streaming

On Thu, Feb 9, 2023 at 9:07 PM Luke Curley <kixelated@gmail.com> wrote:

> Hey Bernard,
>
> On Wed, Feb 8, 2023, 1:01 PM Bernard Aboba <bernard.aboba@gmail.com>
> 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.
>

Luke, should we add that HLS/DASH (they say MPEG-DASH) use TCP and not QUIC
as transport layer?

Behcet

> --
> Moq mailing list
> Moq@ietf.org
> https://www.ietf.org/mailman/listinfo/moq
>