Re: [Moq] Call for Adoption: Use Cases and Requirements for Media Transport Protocol Design

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

Hi, Bernard,

Thanks for providing input on this poll for adoption.

I want to respond to two points you made, without reference to the other
points.

On Tue, Apr 4, 2023 at 4:31 PM Bernard Aboba <[e-mail]>
wrote:

>
> I do not feel that this document is suitable for adoption by the MoQ WG.
>
> Looking over this document, and comparing it to past IETF requirements
> documents such as RFC 7478, this document does not appear to have the right
> structure and organization.
>

Just looking at https://www.rfc-editor.org/rfc/rfc7478.html#page-3 (the
table of contents), I THINK you're saying that there should be specific
requirements under each use case in
https://www.rfc-editor.org/rfc/rfc7478.html#section-2, with the
requirements being summarized in
https://www.rfc-editor.org/rfc/rfc7478.html#section-3.

If that's the comment (about structure and organization), I understand your
point, and we can talk about that, but I want to make sure I understand
your point first.


> Compared with RFC 7478, the use cases are not specific enough, nor does
> the document utilize the use cases to derive specific detailed requirements
> that could guide the MoQ design.
>

Oh, I'd agree with "use cases are not specific enough" (this is, of course,
one of the things I hope we can work on).

At the most basic level, when we were discussing the use cases mentioned in
the MOQ charter, I wasn't able to nail down the difference between
"interactive" and "live" media use cases, although we explored some blind
alleys I had suggestions, and so did other people, but in the end, we just
named enough use cases to justify chartering MOQ.

I don't THINK we've discussed the use cases named in the charter, since it
was approved. There have been two or three proposed additions on the
mailing list, but we haven't talked about them as a group. I think we've
all learned a lot since last fall, about *what everyone else was thinking*.

Just for perspective - Cullen and I had a helpful conversation in Yokohama,
where I understood Cullen to say that the difference between "interactive"
and "live" was really about human factors, not (for example) latency
values, which we were using a year ago in earlier versions of this document.


   - Live means "we both think we are seeing something happen at the same
      time, while it happens"
      - Interactive means "we don't feel like we are taking turns, or
      interrupting each other, when we communicate while we watch something
      happen"

That seems like a useful distinction to me. It's certainly more useful than
other ways we've tried to explain the difference, and it would help us when
analyzing use cases and subsequent requirements.


And, again, thank you for your feedback. It's always useful.

Best,

Spencer

Several of the use cases are so general that it is difficult to tell what
> they are referring to or what the requirements might be.  Not only that,
> but the use cases most likely to justify adoption of MoQ are covered
> barely, or not at all.
>
> As a result, I cannot see how adoption of this document would help the MoQ
> WG progress.
>
> More specific comments:
>
> 3.1.1 Gaming
>
> Is this referring to a cloud gaming service?  Or peer-to-peer game
> remoting? Or is it referring to a service that allows participants to watch
> others play games?  The requirements of these (distinct) services are
> vastly different.  Cloud gaming services typically generate their own video
> so they don't need to ingest it.  P2P remoting services typically need to
> be able traverse NATs so they may need to implement full ICE.  Game
> watching services do not have as a tight latency bounds as cloud gaming and
> may be designed to support a large number of watchers, etc.
>
> This section needs to be broken down into sub-scenarios each with their
> own detailed requirements if there is anything in this scenario that would
> be usefull for MoQ.
>
> 3.1.2 Remote desktop
>
> The section says "Latency requirements are marginally different from the
> gaming use case."  That comment might apply to a cloud gaming or P2P game
> remoting case, but not necessarily to the "game watching" use case. Also,
> as with gaming, there are a spectrum of Remote desktop use cases, including
> P2P desktop remoting (which may require full ICE) and developer
> workstations in the cloud (which typically support multiple monitors).
> Remote desktop scenarios may also involve remoting of sound (typically at
> the system level, but sometimes distinguished by application), separate but
> synchronized communication of mouse position (so as to avoid the increased
> bandwidth used up by handling mouse movement via video coding), etc.
>
> So if in fact this use case is important, it needs to get into much more
> detail.  But that begs the question of why this use case is in the document
> at all, because it typically requires neither ingestion nor relays, two of
> the major features of MoQ.
>
> My overall advice would be to focus on the Live or Hybrid Media
> scenarios.  One way to do this would be to focus on something quite
> specific, such as streaming of live sports.  That use case combines a need
> for low latency with a need for scale and covers elements of the MoQ
> architecture such as ingestion and relays. In contrast to the other use
> cases which have already been deployed to good effect at wide scale with
> non-MoQ architectures, it can be argued that streaming of sports with both
> low latency and large scale is not a solved problem.
>
> ==============
>
> Dear colleagues,
>
> This is a call for working group adoption for "Media Over QUIC - Use Cases
> and Requirements for Media Transport Protocol Design" (https://datatracker.ietf.org/doc/draft-gruessing-moq-requirements/).
> Because it is being issued during the IETF week, we will allocate a
> slightly longer period than normal, and the call for adoption will conclude
> on April 14, 2023.
>
> Given that the working group has a number of participants who are new to
> the IETF, the chairs would like to remind folks that a call for adoption
> represents a decision by the working group that the input document is a
> reasonable basis upon which to build one of the chartered deliverables of
> the working group.  Further changes are expected; the difference is that
> change control moves to the working group.
>
> Please send comments on the adoption to the list.
>
> regards,
>
> Ted and Alan
>
> --
> Moq mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/moq
>