Re: [Moq] Scope of MOQ and ULL Streaming

[Nathan Burr <[e-mail]>]

Thanks Spencer, That does make sense and helps to align my thoughts and
expectations.

On Wed, Feb 8, 2023 at 2:36 PM Spencer Dawkins at IETF <
[e-mail]> wrote:

> <External Email>
>
>
> Hi, Nathan,
>
> On Mon, Feb 6, 2023 at 11:05 AM Nathan Burr <[e-mail]>
> wrote:
>
>> *Discussion #1:*
>>
>> I've spent a bit of time trying to wrap my head around what MOQ is and I
>> feel like this needs to be discussed further. I've seen everything from VR,
>> Conferencing, ULL Broadcasting and gaming as possible use cases. I feel
>> like this is an important discussion because MOQ could be a base layer spec
>> that supports all of these. But that means possibly the need for more
>> specs. Such as VR ov MOQ or ULL Streaming over MOQ. Or it could be a Spec
>> that is more specific to just one thing. The original work around WARP
>> seemed to lean more towards ULL Streaming while RUSH leaned more towards VR
>> and gaming.
>>
>> So where does MOQ fit into all of this? Maybe this has already been
>> discussed and I'm just missing context..
>>
>> My expertise is around ABR Streaming. So I'll be providing more feedback
>> on that side of the conversation of where I would like things to go.
>>
>> *Discussion #2:*
>>
>> What is the target latency? Maybe that depends on the answer to
>> Discussion #1. For ULL Streaming I would think somewhere between 500ms -
>> 2.5s.
>>
>
> Thanks for asking the questions you asked. On these two points, and as you
> guessed, they're related, here's what I think I know.
>
>    - James Gruessing and I spent significant time during the side
>    meetings and the non-WG-forming BOF (and maybe even during the WG-forming
>    BOF) trying to nail down latency targets that people could agree with. You
>    can see our most recent attempt to describe explicit latency targets in
>    draft-gruessing-moq-requirements
>    <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-gruessing-moq-requirements-03__;!!CxwJSw!Lqis7HLFIChTzmjY8XT2v1OWDHPzul_JK9INr1ih8MSmePzd_1cG6lux7rrydLHz88p8AL9Pm4nwJVKyEbqQp2clHRxrEw$>,
>    but you can also see that we've pulled the explicit latency targets from the
>    editor's version
>    <https://urldefense.com/v3/__https://author-tools.ietf.org/iddiff?url1=draft-gruessing-moq-requirements&url2=https:**Afiestajetsam.github.io*draft-gruessing-moq-requirements*draft-gruessing-moq-requirements.txt__;Ly8vLw!!CxwJSw!Lqis7HLFIChTzmjY8XT2v1OWDHPzul_JK9INr1ih8MSmePzd_1cG6lux7rrydLHz88p8AL9Pm4nwJVKyEbqQp2dReLmjlQ$>
>    .
>    - It turns out, that was a Bad Idea, because there are a large number
>    of use cases with similar, but not the same, latency targets, and we even
>    tripped over people who were apparently talking about the same use case,
>    but didn't agree on the same latency targets.
>    - Where I think MOQ WAS, at charter time, was thinking that the MOQ
>    protocol itself should be trying to minimize the protocol-induced latency
>    users experience, without reference to what the latency users experience
>    from any given implementation, network architecture, or deployment. I've
>    heard "no one wants to be HIGH-latency", so saying that we want to minimize
>    latency (for example, minimizing RTTs required to do things), and let
>    people decide whether the MOQ protocol is low-latency *enough *for
>    their use cases, made more sense than targeting a latency range.
>
> Of course, now that MOQ is chartered, people who weren't involved before
> the WG-forming BOF are becoming involved, and I think we're still learning
> what the WG thinks now.
>
> Does that make sense?
>
> Best,
>
> Spencer
>
>