MoQ Virtual Interim 2025-09-10

Editor slides:
https://datatracker.ietf.org/meeting/interim-2025-moq-26/materials/slides-interim-2025-moq-26-sessa-moqt-prs-for-910-01

PR #949

(Slide 2,3)

• https://github.com/moq-wg/moq-transport/pull/949

• Priority Not Present complexity worth saving a byte per group?

  • Note: some datagram use cases may have 1 object per group
  • Alan leans towards proposal b
  • Martin has slight preference for the simpler to implement a
  • Ye-Kui sees benefit of proposal b compression

• Use a bit for Object ID=0?

  • Suhas: consistency across SUBSCRIBE/FETCH is desireable
    • Alan: FETCH is different enough we might not get true
      consistency

Summary: 1 b and "no" on 2

PR 1159 consolidate errors (slide 4)

• https://github.com/moq-wg/moq-transport/pull/1159
• Ye Kui in favor
• Suhas to comment on PR

No objections voiced

(Note: this PR is about consolidation, not every error-code issue)

Issue 1182 proposal for REQUEST_OK (slide 5)

• https://github.com/moq-wg/moq-transport/issues/1182
• Looking for more feedback before PR
• general support voiced by a few people (Will, Ye Kui, Martin, ...)
• Suhas describes an alternative approach to consolidation
  • question becomes about whether to reorder fields/params

Alan offers to make at least one, mayb two PRs in the next week or so:
- add this
- reordering

PR 1210 - Parameters for Group Order, Subscribe Priority and Subscription Filter (slide 6, 7, 8)

• https://github.com/moq-wg/moq-transport/pull/1210
• Slide 7 show target changes, next targets

• Questions (slide 8):
  1) Should relative Filter Types be allowed in PUBLISH_OK or
  SUBSCRIBE_UPDATE (no way to get Largest back)?
  2) You can’t change End without changing specifying Start; Is that
  a problem?
  3) Omitting Group Order is slightly funky
  4) Do we feel good about leaving Forward “inline”?
  5) Other candidates: Expires and Largest Location

  Discussion (40ish minute mark)
  ...

  Conclusions:
  - please look at PR and leave comments, it closes a ton of issues

PR 1060 NEW_GROUP_REQUEST (slides 9,10)

• https://github.com/moq-wg/moq-transport/pull/1060
• DoS issues a concern

Mike to make slides for Toronto with alternative proposal, otherwise PR
seems close

2025-09-10 MoQ interim meeting (9-10 am PDT)

The following notes were taken by Ye-Kui Wang.

All Times UTC
Administrivia (1600-1605)

On FETCH serialization (PR #949) (1605-1615)

Alan presented slides (10 pages) for this topic.

Page 2: Some metadata compression ratios were shown.

Page 3: Open questions

1) Priorty Not Present
2) Use a bit for Object ID = 0
Martin, Will, Victor made comments.
Will: We should use the remaining bits.
Victor: Datagrams and FETCH situations are different herein.
Ye-Kui: 1.b is more efficient. Alan confirmed.
Suhas: No action on item 2.

Agreed to go with 1.b (previous Object in this Subgroup (if any),
otherwise previous Object).
No actio on item 2.

Page 4: Consolidate all on the Error Message types

*_ERROR => REQUEST_ERROR
Note that this does not change the semantics of any existing error code.

Ye-Kui: Sounds like a very good clean up to me.
Suhas: Agree in principal. Need to review it.

Page 5: Issue #1182 (Proposal for REQUEST_OK Message)

Will asked a question.
Ye-Kui and Martin expressed supports. Ye-Kui said that this is somehow
similar to the previous one on consolidating error message types.
Suhas asked details of the design with the proposed changes and
suggested a specific way to make the changes. Alan explained.
Reorder the fields and put the parameters first?
Alan said he could make two PRs, one with the reording and the other
without the reordering.

Pages 6-8: PR #1210 Parameters for Group Order, Subscriber Priority, and Subscription Filter

Suhas: SUBSCRIBER default Group Order should be Ascending rather than
don't care.
Ye-Kui: On item 3. I feel that it is OK to have different default values
for Group order for different messages. For SUBSCRIBER, agree with
Suhas.
Tim: There is a way for the subscriber to know the publisher's
preference.
Suhas/Alan: Discussed whether there should be an error in reaction to
Group Order information missing or not correct etc. It seems this
information should not result in an error situation.
Alan asked for more reviews of the PR.

Pages 9-10: PR #1060 NEW_GROUP_REQUEST

Tim and Alan discussed handling of multiple requests. Alan said that the
OP just needs to be able to handle multiple requests, including those
that did not want.
Suhas: Support the changes in general. Lot of comments...
Alan asked about acknowledgement.
Mike: Prefer not to add requirements on Relays.

The following agenda items were not discussed at this interim meeting:

• REQUEST_ERROR (PR #1159) and REQUEST_OK (PR #1182) (1615-1630)
• New Parameter PR (# TBD) (1630-1635)