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

[Bernard Aboba <[e-mail]>]

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

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