Re: [Moq] Scope of MOQ and ULL Streaming

[Nathan Burr <[e-mail]>]

A lot of the CDNs have done a lot of work to support newer push data flows.
At Edgio ( or whatever it was called ) we did a lot of work to support
chunk-transfer encoding so that all data was streamed from origin to edge
as the encoder was writing its output. The nice thing about it, after the
chunked transfer PUT was complete, the full segment was the same as a high
latency segment. so everything was already cached. The problem with chunked
transfer is it was nearly impossible to measure line speeds in the browser.

The best alternative was to keep our data flows the same but signal in the
manifest when a part was fully available at the origin using byte-range
requests. Everyone in the industry as far as I'm aware did the same thing.

If MOQ ends up being something similar to chunk-transfer but with
prioritization and better bandwidth estimate, it would be a good step
forward.

What I'm trying to say is that I don't see the step from chunked transfer
encoding to MOQ as being that big of a leap for most CDNs. I would imagine
that the biggest issue for them is if the connection is persistent or not.
Which might be something we want to address here.

   - How long should connections be open for?
   - Is there a way for the server to tell the client to go away
   gracefully? So the client can connect to another server or another CDN and
   switch the stream with minimal issues before closing the current stream.

The other thing is that I don't think CMAF makes sense here. And perhaps
that is beyond the scope of MOQ. For lower latency interactive content,
CMAF isn't a great format. But it would make more sense for CDN
efficiency.

So as far as adoption goes, If you want to make it easy for adoption.
chunk-transfer v2 makes sense. But I don't think you will ever see latency
lower than 1 second. I would estimate 1-2 second range still.

I don't think that's what we are really wanting to do here. Is it?

-nate



On Fri, Feb 10, 2023 at 1:07 PM Charles 'Buck' Krasic <
[e-mail]> wrote:

> <External Email>
>
>
>
>
> On Fri, Feb 10, 2023 at 9:20 AM Behcet Sarikaya <[e-mail]>
> wrote:
>
>>
>>
>> On Thu, Feb 9, 2023 at 9:07 PM Luke Curley <[e-mail]> wrote:
>>
>>> 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.
>>>
>>
>>
>> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/moq
>>> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/moq__;!!CxwJSw!PhFElR1BeRYdZpNkxwQtHqoXTVKb7zEMs-XiV78gEpEKynMZaN6MbtUFjXRDEcbry-b67GApTHYYY2BjYWVxCCPg6nfu$>
>>>
>> --
>> Moq mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/moq
>> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/moq__;!!CxwJSw!PhFElR1BeRYdZpNkxwQtHqoXTVKb7zEMs-XiV78gEpEKynMZaN6MbtUFjXRDEcbry-b67GApTHYYY2BjYWVxCCPg6nfu$>
>>
> --
> Moq mailing list
> [e-mail]
>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/moq__;!!CxwJSw!PhFElR1BeRYdZpNkxwQtHqoXTVKb7zEMs-XiV78gEpEKynMZaN6MbtUFjXRDEcbry-b67GApTHYYY2BjYWVxCCPg6nfu$
>