Re: [Moq] Scope of MOQ and ULL Streaming

[Bernard Aboba <[e-mail]>]

Spencer said:

"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)"

[BA]  It seems to me that the MoQ "conferencing" use case may not be the
same as the "conferencing" use case described in RFC 7478 Section 2.3.11
(see: RFC 7478: Web Real-Time Communication Use Cases and Requirements
(rfc-editor.org) <https://www.rfc-editor.org/rfc/rfc7478#page-14>).
Instead, it might be more closely related to the "Live Media" use case,
with some additional requirements (and a different set of success
criteria).

For example, I have seen "ingest, syndication and streaming" used in
scenarios that to the end user, appear to be close cousins of
conferencing.  For example, to produce meetings with high production values
in which people can ask questions of a presenter. While this might be more
of a "webinar" than a "conference",it is often today implemented with
conferencing technology (e.g. a MoQ interim hosted on MeetEcho).  But it
seems plausible that MoQ could produce technology to enable that use case,
with only subtle differences tipping off participants to the difference
(higher production values and support for a much larger number of
participants).






On Thu, Feb 9, 2023 at 4:09 PM Spencer Dawkins at IETF <
[e-mail]> wrote:

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