Re: [Moq] Scope of MOQ and ULL Streaming

On Fri, Feb 10, 2023 at 9:20 AM Behcet Sarikaya <sarikaya2012@gmail.com>
wrote:

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

Eh? The H is for HTTP, and HTTP/3 is over QUIC. Moreover, there have been
large scale deployments of HLS and DASH over HTTP/3 + QUIC for several
years now.

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