MoQ Interim, 18 December 2024

Bluesheets:

  1. Martin Duke (Google)
  2. Victor Vasiliev (Google)
  3. Magnus Westerlund (Ericsson)
  4. Sebastian Rust (TU Darmstadt)
  5. Suhas Nandakumar ( Cisco )
  6. Mathis Engelbart (TUM)
  7. Cullen Jennings (cisco)
  8. Giovanni Marzot (Vivoh/MarzResearch)
  9. Mike English (Norsk by id3as)
  10. Mo Zanaty (Cisco)
  11. Will Law (Akamai)
  12. Alan Frindell (Meta)
  13. Ian Swett (Google)

Agenda:

Chair Introduction (5 min)
MoQT Issues:

Chair Conclusion (5 min)

Notes:

Joining Fetch PR #638

Mike English presented and lead discussion on the PR.

Going through the proposal and noting that there are cases where an
relay will be unable to answer immediate and itself have to go upstream
to subscribe and request media. An interesting case is if the relay has
no media, can it forward the Join upstream. But there are clearly
special cases, like subscribe has just been stared but media has not
been received. Can the relay send a join in this case? Will it give the
desired result?

A goal with the proposal is to ensure that the algorithm results in a
standard fetch with a particular set of parameter values. It should
always be possible to point to regular fetch's behavior. So if some
behavior is desired for Join's fetch part it should be added to fetch.

Non-contignous group ids will have the result that the relay will have
to ask upstream if these groups exists or not. There does not appear a
way to avoid this, and this property is the same for fetch.

Cullen trying to determine what happens if there are many clients
joining in a short interval and performing the same Join. So for the
first client it will forward the Join. What happens then with the second
and that has a somewhat later join time. Can that result in this second
would miss some data because the algorithm results in different result.
It appears that a relay have to either process this locally or if it
just forwards it any subsequent request have to be processed locally and
resolved when data is available. The specification have to be careful to
not assume about use cases, but a client have to get a consistent
behavior.

Mo asked is the Join + Fetch more complicated then the old Subscribe?
Mike thinks the clarity gained is what is past and future.
Ian asked what will we happen if you asked far back. What happens on the
delivery and with the back pressure. Cullen noted that it will depend on
the priority, as if the subscribe priority is higher then the subscribe
will be delivered. Likely limited to a small time frame into the past.

Mike's take away
What semantics do we want to have when we join a stream? Other questions
raised might apply to Fetch in general. Some things that he can clarify
on the PR.

If anyone wants sub-groups in the past please put in a PR, otherwise
that is the answer.

Will this be mergeable when the Nits are addressed: 5 thought it is
mergable. No objections.

Remove Group Order for Subscribes [PR #636] (https://github.com/moq-wg/moq-transport/pull/636)

Ian asked if there was any objections to the changes to only allow.

Victor Vasiliev had issues with this change.

Mike English had an write up of lost functionality in the Issue compared
to just using the delivery timeout.

Conclusion is that this do needs more discussion.

Next Interim 8th of Jan.