Re: [Moq] Scope of MOQ and ULL Streaming

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

Hi, Bernard,

On Thu, Feb 9, 2023 at 12:57 PM Bernard Aboba <[e-mail]>
wrote:

> On Thu, Feb 9, 2023 at 07:54 Spencer Dawkins at IETF <
> [e-mail]> wrote:
>
>>
>> Where I think MOQ is, is that we agreed to charter MOQ for a minimum of
>> three use cases ("use cases including live streaming, gaming, and media
>> conferencing <https://datatracker.ietf.org/wg/moq/about/>") as a
>> starting point, we haven't written down the differences between those three
>> use cases, and we've been steadily removing attributes in the use cases
>> section of the requirements draft (so, no longer distinguishing among the
>> use cases based on latency, in the editor's version
>> <https://fiestajetsam.github.io/draft-gruessing-moq-requirements/draft-gruessing-moq-requirements.html#name-use-cases-informing-this-pr>
>> ).
>>
>
> [BA] The problem is that these use cases are not equally likely to adopt
> MoQ. Today game streaming and conferencing deployments often use WebRTC.
> Those game streaming deployments that don’t use WebRTC A/V typically don’t
> need intermediaries or ingestion so interop efforts focus on API
> availability in different browsers, rather than protocol support.
>

I know that we had a LOT of conversations before the WG-forming BOF about a
desire to use QUICR for interactive applications, but (as I understand it)
we've been focused on protocol specification, rather than anything about
how to actually use the protocol. If I'm correctly quoting Ted, this was
characterized as systems engineering, rather than protocol design. It makes
perfect sense to exclude those considerations from the protocol
specification(s), but it also makes perfect sense to have a place where
they belong.

I have thoughts about where to put that material, but I want to see if
anyone else wants to work on that material, before talking about a
location.


> In contrast, live streaming (which to my mind includes large scale Town
> Hall Meetings and Webinars) has a clear need to evolve ingestion beyond
> RTMP, and on the distribution side, intermediaries are common. While there
> is an incumbent (HLS/DASH), there are needs that are not yet met that could
> be articulated.
>

This is also my understanding. You might notice that the Live Media use
case subsection in the requirements draft
<https://fiestajetsam.github.io/draft-gruessing-moq-requirements/draft-gruessing-moq-requirements.html#name-live-media>distinguishes
between ingest, syndication, and streaming, where the interactive use cases
<https://fiestajetsam.github.io/draft-gruessing-moq-requirements/draft-gruessing-moq-requirements.html#name-interactive-media>
do not.

(The structure of the Live Media use case section is from James Gruessing.
I thought he was right, but he was the one who was typing)


> Since a requirements document is not an applicability statement, you don’t
> need to worry that omitting a use case will inhibit its development.
>

Now ... that's an interesting reminder that Applicability statements can be
standards-track. Definitely something for me to file away for the future.

Best,

Spencer