Re: [Moq] Scope of MOQ and ULL Streaming

[Spencer Dawkins at IETF <[e-mail]>]

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://datatracker.ietf.org/doc/html/draft-gruessing-moq-requirements-03>,
   but you can also see that we've pulled the explicit latency targets from the
   editor's version
   <https://author-tools.ietf.org/iddiff?url1=draft-gruessing-moq-requirements&url2=https://fiestajetsam.github.io/draft-gruessing-moq-requirements/draft-gruessing-moq-requirements.txt>
   .
   - 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