Re: [Moq] Scope of MOQ and ULL Streaming

[Suhas Nandakumar <[e-mail]>]

Hello Nathan
Few responses inline under [Suhas]

On Fri, Feb 10, 2023 at 11:10 AM Nathan Burr <[e-mail]>
wrote:

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


[Suhas] This was discussed during the recent interim on separating
container format, There has  some thinking started already on these lines.


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

[Suhas] Sub-seconds latency for interactive flows is part of MoQ's scope.



> -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$
>>
> --
> Moq mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/moq
>