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

Spencer said:

"

   -

   My suggestion is that we work through live sporting events*, and use the
   resulting set of attributes as a template for further use cases*.

"

[BA] I think this might be a fruitful exercise.  One reason why I suggested
sporting events is that sports leagues are currently trying to figure out
the transition from traditional distribution over cable to the new world of
streaming.  Since "broadcast rights" represent a significant fraction of
team revenue, the stakes are high, as is interest in potential approaches
that can deliver high scale and low latency as well as other benefits such
as enhanced audience engagement.

One potential way to approach this might be to consider the requirements
for one of the world's most popular sporting events:  The World Cup.  I am
not a soccer fan (I'm more interested in baseball or American football), so
it's probably best that I avoid suggesting requirements that might be
appropriate for those other sports but might not fit in well with soccer.
However, I have witnessed World Cup "viewing parties" where people get
together to watch early matches. The level of interest seems high even in
the early rounds, and my understanding is that by the later rounds the
viewing audience is extraordinary in scale and intensity of interest.

On Sun, Apr 23, 2023 at 7:58 PM Spencer Dawkins at IETF <
spencerdawkins.ietf@gmail.com> wrote:

> Dear MOQ,
>
> The MOQ chairs polled the working group on adoption of
> draft-gruessing-moq-requirements-04
> <https://datatracker.ietf.org/doc/draft-gruessing-moq-requirements/> on
> March 25, asking for feedback by April 16 (extended due to overlap with
> IETF 116 meeting dates).
>
> TL;DR: So far, the chairs and I have seen two responses to the poll, and
> James and I know what to do with draft-gruessing-moq-requirements-04
> <https://datatracker.ietf.org/doc/draft-gruessing-moq-requirements/>,
> based on the comments we've received, before submitting a working group -00
> version as a basis for further work.
>
> But it is fair to note that we haven't gotten a lot of feedback.
>
>    -
>
>    If you think our responses to the comments summarized below will lead
>    MOQ to a draft revision that's suitable for adoption, it would be great to
>    say that, even if it's just saying +1 on the mailing list.
>    -
>
>    If you think other changes are required before you could support
>    adoption of this draft, please tell us - ideally by May 1, so that we
>    can provide a draft revision before the next MOQ meeting (which is likely
>    to be an interim, based on discussions at IETF 116).
>
>
> The details follow.
>
> Best,
>
> Spencer
>
> Bernard Aboba replied on April 4
> <https://mailarchive.ietf.org/arch/msg/moq/CfdP-_fIhgV2nME-w0GaKc8_2Tw/>,
> with a "not suitable for adoption" and comments. After trading email with
> Bernard, here's what I think is needed before adoption.
>
>    -
>
>    Bernard was concerned with the structure of the document, providing RFC
>    7478 <https://www.rfc-editor.org/rfc/rfc7478> as an example of a
>    better structure.
>    -
>
>    After discussion with Bernard, it seems that the real problem is that
>    the use cases in draft-gruessing-moq-requirements-04
>    <https://datatracker.ietf.org/doc/draft-gruessing-moq-requirements/>
>    are not described in enough detail to analyze for requirements, or even to
>    spell out what the differences are between (say) remote desktop and gaming.
>    I'm sympathetic to that point of view, since we haven't discussed MOQ use
>    cases in detail since the charter discussions nearly a year ago.
>    -
>
>    Bernard suggested that we focus on describing specific use cases in
>    more detail, focusing on use cases that are most likely to benefit from
>    adoption of MOQ (so, do they need ingest, do they need relays, etc.) His
>    suggestion is to focus on live sporting events first, because it
>    combines requirements for high production values, low latency and high
>    scale. Live sports has also included features such as “rewind”, audience
>    feedback, co-watching and  “together mode”, and I agree with that.
>    -
>
>    We've had an open issue to Agree on attributes for each use case that
>    we need to drive requirements for protocol engineering
>    <https://github.com/fiestajetsam/draft-gruessing-moq-requirements/issues/74>
>    for a while.
>    -
>
>    My suggestion is that we work through live sporting events*, and use
>    the resulting set of attributes as a template for further use cases*.
>
>
> Lucas Pardue replied on April 12
> <https://mailarchive.ietf.org/arch/msg/moq/qOjHbWpGyhRsIiaUgZHgB3EWGRk/>,
> with a "suitable candidate for adoption" response, and comments.
>
>    -
>
>    It's not perfect and needs further development but that is sort of the
>    point of adopting it.
>    -
>
>       I agree with this point, especially given Bernard's comments above.
>       -
>
>    If we don't adopt this document now, when and how would we expect that
>    milestone to be achieved?
>    -
>
>       That's an excellent question, of course.
>       -
>
>    As a point of administration, I don't see a corresponding milestone
>    for submission of a document to the IESG. Can I ask the chairs to clarify
>    if the intention is to adopt and develop a draft but not seek taking it
>    through to an RFC*?
>    -
>
>       I replied to this one, not as a MOQ chair, saying that the omission
>       was intentional (if I remember correctly) and is consistent with
>       the IESG statement on support documents
>       <https://www.ietf.org/about/groups/iesg/statements/support-documents/>
>       (a reasonable summary is "don't publish informational working group
>       documents in archival series unless they have archival value").
>       -
>
>       Unless the chairs see this differently, *it's worth us adding a
>       statement about that in the draft itself, because we've been asked about
>       this on at least three occasions. *
>
>
> --
> Moq mailing list
> Moq@ietf.org
> https://www.ietf.org/mailman/listinfo/moq
>