MOQ Toronto Hybrid Interim 2025-09-25

Bluesheet

1. Michal Hosna (CDN77)
2. Will Law (Akamai)
3. Daniel Fay (Meta)
4. Zafer Gurel (Constructor Tech - Ozyegin Uni)
5. Ali C. Begen (Ozyegin University)
6. Mo Zanaty (Cisco)
7. Cullen Jennings (Cisco)
8. Suhas Nandakumar (Cisco)
9. Alan Frindell (Meta)
10. Ye-Kui Wang (Bytedance)
11. Mike English (Cloudflare)
12. Weihang Ding (Huawei)
13. Martin Duke (Google)
14. Magnus Westerlund (Ericsson)
15. Ian Swett (Google)
16. Luke Curley (me)
17. Christian Huitema (Private Octopus)

Notes

Note Taker: Daniel Fay

0930-0940 Administrivia

Interop Report (Mike)

Interop slide:
https://docs.google.com/spreadsheets/d/1uBVmUWdm-UZeEQQlPMBSNOa2L7xDwc7cTXwTXX8fSfw/edit?usp=drivesdk

Mike:
Draft 14 not a huge lift, MoQ.rs coming from 7 -> 14 was difficult (Main
issues related to subgroup parsing).

Suhas:
Most features tested bewtween Cisco with Moxygen as relay. Limited
support for immutable header extensions.

Alan: Wrote draft for MoQTest (dynamic track generation from full
trackname). Would that be useful for automated test run?

Mike: Yes. There are a lot of different features to test, client,
server, with/without relay.

Cullen: Would anyone running relays be willing to make logs public?
Would make testing against public relays easier.

Zafer: Agree MoQTest client would be very helpful. Standardized log
format would also be useful.

Will: We could add a log track that is negotiated in setup.

Victor: That doesn't work if your MoQ implementation is broken.

Christian: I don't like exporting logs through application that is being
tested. QLOG for MoQ would be a reasonable standard

Mike: Self interop misses lots of errors, cross interop important.
Jumping in is a lot easier by participating in interop

Christian: We should invest more in interop runner.

Alan: This would be good, its just a lot of work.

Next Interim Planning / Meet in Shenzhen? (Martin)

Virtual Interims

Cullen: Wednesday meetings are hard, can we move to Mon/Fri?

Martin: Polled room, Monday is better.

Will move the future meeting scheduled from Wednesday (Oct 8) meeting
to Monday (Oct 6 and Oct 20th).

Chairs Note: The meeting the 8th could not be moved as it would violate
IETF's scheduling rules.

Next Hybrid Interim

Martin: Raise hands if you will attend Shenzhen (3 hands raised)

Alan: Does that change interim scheduling rules?

Martin: No, still can't schedule near full IETF

Martin: Should we have more hybrid interims? No opposition

Martin: To align with mile high, target week before or after

Tentative plan: Feb 9-12 in Denver. Will potentially do standards on
first two days and follow with interop. Will follow up with list
announcement

LOC (Mo)

Slides

Change to metadata: LOC headers moving to object payload, to avoid
combining media and relay extension space

Mo: Separates the spaces, also allows for E2EE media headers

Christian: Like v2 format, making entire payload obscure to relay
simplifies processing

Victor: If things are encrypted, should go in payload, if not in
immutable headers

Luke: Comes down to layering. LOC extensions don't neccesarily need to
be relay visible, but if a header is intended to target relay behavior
it should be in MoQ header

Mo: Plan is that any extension header which is intended for relays will
be double registered in MoQT and LOC

Luke: Should create MoQ headers and application header block and define
separately.

Cullen: Payload is application defined, it can put whatever it wants and
should be irrelevant to relay behavior.

Alan: Can we table this and discuss with concrete proposal.

Mo: Draft 14 includes single extension registry, containing relay
mutable, immutable extensions, and private extensions (no registry,
contained in object payload)

Luke: I like the proposed design, keep application data isolated to
object payload

Suhas: This design changes the immutable headers we register, will need
to re-review them after this.

Ye-kui: Prefer v1 architecture. Some LOC extension headers are defined
in MoQT draft and advise relay behavior.

Ian: For SMAF decision, do whatever is most efficent. We can wrap on
client side to make migration/compatibility easier.

Will: CARP requires LOC and CMAF compatibility, no benefit of tunneling
LOC inside of CMAF

Ali: Agree with Will. Consider renaming WARP/CARP

Mo: If we want to rename, do so soon

Mo: Seems no interest in combining LOC and CMAF. May add text to explain
transmuxing.

Conclusion: Will have follow up discussion on header separation and
encoding

Break (Return 10:50 local)

Privacy Pass for MoQ

Draft

Magnus: Comment on privacy draft. Should we have an adoption call?

Cullen: We should make an adoption call.

Ian: What's concern about adopting it?

Magnus: I just want to see that there is some level of support/interest

Martin: Original conclusion was we would have an authentication
method. This is a second

Alan: I think we have a lot of items under work, we shouldn't burn time
on just adding new things if they're not necessary.

Mike: Agree with Alan

Victor: Focus on bigger items, we can adopt

Magnus: Will start an adoption call.

Will: Would support multiple authentication drafts, think group can
parallelize and that shouldn't block new work.

WARP, etc (Will)

• WARP (25min) https://github.com/moq-wg/warp-streaming-format
• CAT-4-MOQT (20min) https://github.com/moq-wg/CAT-4-MOQT
• CARP (10min) https://github.com/wilaw/carp

WARP Update Slides
CARP Update Slide

Issue #68

Recommended changes:

• Split timeline track into two tracks, one for only delta updates and
  one for joining with full history.
• Add version of media timeline in catalog

Luke: We could add key-value pairs to make structure less strict and
more extensible

Issue #60

Will: Add track info as URL fragment

Magnus: Fragment are defined in context of media type of the resource.
URI review list or the HTTP directorate might be useful to ask for
feedback.

Victor: Fragments explicitly disallowed in WT, can be stripped by player

Alan: Did you explore templated URLs? Also is slash a namespace
delimiter?

Will: In this format the slash is a delimeter, no slashes in track
namespaces

Cullen: I think this might violate how to use fragments. There's a lot
of potential issues here, contact Ted Hardy for advice on what to do
here.

Cullen: Could pass catalog as query parameter.

Victor: That comes with its own problems.

Zafer: I would prefer putting it in a query parameter over fragment.

Alan: There's a lot of potential design considerations, lets discuss
more on the issue

Request for Implementation Experience

Mike: Should we make MoQMi a WARP media test case

Alan: MoQMi expired. Could make an extremely simple new version that
aligns with current designs and use that as testing point

Mo: We should identify essential components for interop point

Will: Catalog with live audio and video, next step is to add timeline

Naming

Will: "WARP" is marketting-ish name, should we change to technical name?

Christian: IETF uses non-technical name in plenty of places, nothing
wrong with that.

Show of Hands:
Should we change the name from WARP?
3 hands raised

Should we not change the name?
1 hand raised

Conclusion: Will to raise name change proposal on list

CARP

Will: Request similar simplified interop point as with WARP to gain
implementation experience.

Will: Request adoption.

Show of hands: Should we adopt CARP by group?
11 in favor
0 opposed

Conclusion: Strong support to adopt. Name should change.

Mo: Will CARP support all CMAF

Will: Carp has no restrictions on media codecs

Ali: MoQ should support all CMAF applications

Mo: This means everything can come over this, application side needs to
support it

Will: All clients don't need to support everything, they just need to
select what they can use. Protocol should support all, application can
then select.

CAT-4 MoQ

Cullen: Why not put DPoP draft within C4M draft?

Will: Can be used elsewhere, keeping it separate allows it to be more
easily used for other applications.

Christian: If draft is separate because it is useful elsewhere, it
should not be written within the MoQ group

Suhas: Draft is submitted to OAUTH group, not MoQ

Christian: We should have time limit, if OAUTH has not adopted it in
sufficient time we should incorporate it ourselves

Magnus: This may be outside of charter to take under WG

Cullen: OAUTH group is going to tell us this belongs under MoQ purview

Lunch

Target return at 12:30PM

1230-1430 General MoQT Issues (Alan, Ian)

Varints PR#1016

Alan: Different encodings allow more in 1 byte varints. Does anybody
want to explore changing the varint encoding?

Martin: Object IDs are the most important. Would love to see more
details/graph.

Mo: Most common encoding is 1-bit leading bit to signal longer encoding.

Luke: Who cares lul.

Alan: I'm going to go with what we have.

Martin: I don't want to change all of my code and tests again.

Mike: What data do people want?

Alan: Going to move on. Do we want to include pseudo-code?

(vote no)

Alan: What do we do with the trailing bits?

Martin: Does forcing all zeroes make things more extensible?

Christian: Don't invent more varint encodings.

Ye-Kui: The code in the PR is very good.

Alan: Going to go with zeroes in this version.

Mo: This is different than other VarInt encodings.

Alan: I didn't want to spend 15 minutes here. Moving on.

FETCH priority update

Alan: Can you change the priority of FETCH after the initial request?

Will: Yes.

Alan: Is everyone okay with using SUBSCRIPTION_UPDATE for FETCH?

Suhas: Make a new message if it doesn't have the same functionality.

Martin: Does anybody have to have this?

Zafer: Would we have to create another stream for this?

Show of hands: 4 yes, 4 extension, 8 live with current design.

Invoking past deadline.

Alan: Do you want text indicating you need to cancel the fetch?

Answer: Mo, a single 1 sentence.

TV vs TLV #1184 #1221

Alan: Proposing priority and group order are TV. Filter, largest object
because they're predefined structs.
Alan: Everything else TLV. Type encodes the size in many cases (boolean,
varint, length prefixed).
Everything has been moved to the parameter blob.
How much do people care?

Mike: Length is useful for skipping stuff you don't care about.

Mo: This is control plane so it doesn't matter much. Prioritize a
generic parser.

Alan: Cullen wanted TVs.

Martin: This is annoying to save a few bytes.

Alan: Who wants to keep the current draft? Varint or length present
flag, that's it.
5 yes. Cullen assumed no, not in the room.

Alan: May be overtaken by events.

(Cullen in the room now)

Alan: Now that everything is a parameter, people would prefer that all
parameters be encoded the same. No special encoding for some types.

No more progress will be made, move on.

Extensibility

Alan:
Extensible: SETUP, Extension Header Types, Auth Token Types
Not Extensible (must be negotiated via version or extension): Message
types, enum values, stream types, datagram types.

Cullen: Terminology is different.

Alan: Renamed to Requires Negotiation.

Alan + Cullen: Disagree. Both leave, somebody else drive.

Ian: Skipping ahead.

Overlapping prefixes in UNSUBSCRIBE_NAMESPACE #1124

Ian: Do you need to unsubscribe_namespace to each subscribe_namespace.

Room: Yes

Protocol error to receive an ANNOUNCE_CANCEL before ANNOUNCE_OK/ERROR #1070

Martin: You should send ANNOUNCE_ERROR, not ANNOUNCE_CANCEL.

Suhas: Don't we need ANNOUNCE_CANCEL?

Martin: We could allow either ERROR or CANCEL? Just send ERROR if you
haven't sent OK yet, then send CANCEL.

Luke: Protocol violation.

Ian: Protocol violation, MUST NOT do it, MAY close the connection
(Christian).

Difficult to limit subscription resource consumption #869

Ian: Does anybody care? Flow control for subscriptions. Very difficult
to do in the current design.

Mo: Should do a comprehensive security review.

Ian: Do people want an extension? Separate draft?

Alan: What do you need?

Ian: A way to stop slow clients and be proactive about it. We have this
problem all the time with HTTP.

Alan/Cullen: Best thing is 5 slides on the problem.

Extensibility Again (the return of the king)

Alan: Maybe extensible? 0-RTT

Ian: Every extension needs to shove it into resumption token.

Ian: Can't pipeline stuff unless you're going to remember it.

Alan: Are error codes extensible? REQUEST_ERROR, RESET_STREAM,
STOP_SENDING, PUBLISH_DONE, SESSION_CLOSE.

Alan: What should a receiver do when it receives an error. Is it
retryable? Immediately? Refresh auth?

Luke: Ability to return arbitrary error codes for applications.

Martin: What can you do in HTTP?

Cullen: Information about what you need to do after receiving an error.

Daniel: Define the behavior separate from the code.

Michael: Error propagation.

Luke: First digit in HTTP kind of defines what the client should do.

Will: Doing something similar when standardizing error codes.

Alan: More structure around error handling, splitting the code into
parts.

Martin: Different actions based on the method. Volunteering.

Mo: Do we just copy HTTP?

Ian: Every client is just going to retry anyway.

Alan: GREASE before I go. We need to grease the things that are
extensible.

Ian: Yes grease everything.

Alan: Signal to grease everything.

Ian: What about parameters? Can the client just insert a random
parameter?

Cullen: Ignore it except for a pre-defined range.

Break

Revisiting Extensibile

Ian: Want all parameters to be required or optional, not having separate
classes.

Cullen: Parameters are hop-by-hop. Gotta negotiate subscribe v2 if you
want to add more.

Track Extensions (#1176)

Ian: Use cases, catalog-less, compression, extension point, filter
criteria? Do we need it?

Mo: Need it so it's reliable/deterministic.

Luke: Do you need to update it?
Mike: Do you need to cache it?
Martin: Can we make it an extension?
Ye-Kui: Redundancy with catalog.

Ian: Could do Mo's filtering thing using this track metadata. Do people
need this?

Mike: Would rather have more stuff in the payload.

Ian: Going to park it.

Mo: There's a line that says metadata should not be an object extension
unless it's used by relays or the transport.

Should we remove INTERNAL_ERROR #1162

Ian: I'd rather just keep it.

Cullen: What's lacking is what you're supposed to do with this error.

Martin: Can we park this and merge it into the error code refactoring?

Magnus: Link it with issue #1175.

Cacheability of MALFORMED_TRACK

Ian: What should a relay do when it detects a malformed track?

Victor: What do you do on a malformed track?

Martin: Close the publisher's connection and send MALFORMED_TRACK to
downstream subscribers.

Ian: Current draft says you tear down the subscription, but says nothing
about cachability.

Victor: If relay receives a bad object it should reject it.

Martin: The relay can't detect this. WHITEBOARD. Good guys publisher,
bad guys publisher.

Martin: Bad guys publish track to two relays, relays merge it to one
subscriber, don't cause collateral damage. That's why we don't kill the
session.

Christian: Not a useful design to have broken connections.

Magnus: Error might be several steps upstream.

Christian: How do you get the publisher to fix what it's doing? You want
the original to know it's doing something bad.

Ian: There are no error code today in Unsubscribe. But maybe the best is
to add something to make it clear something was wrong with what the
publisher sent.

Victor: Don't close the entire connection so you know what subscription
caused the error.

Martin: Bad clients could just abuse the error code in UNSUBSCRIBE. Have
to avoid, but enable fault finding through logs etc.

Mo: I don't think we know which upstream was at fault.

Ian proposal was to change unsubscribe to unsubscribe and do not cache
the broken data.

Luke: You should cache the error to avoid returning an error.

Victor: There is a point of clearing the cache and going
upstream.

Luke: Risk to nuke the site, by having to go upstream and fetch.

Martin: What is the minimal we can do to move forward. Will one recover
the session by going upstream?

Cullen: We should discuss some of the issues that could come up. Very
similar to HTTP.

Mike: Agree to not cache malformed data because you can't represent it.

Cullen: Cache that you can't serve a track, at least for some point of
time.

Will: How do you clear the cache if the bad client was first to get the
data into cache?

No conclusions.

Do we need Auth Alias #969

Ian: Do we need this optional compression feature?

Martin: Would it be easier to fix the issues or move it to another
draft.

Cullen: Should have Alan in the room. Might be good to update token once
and reuse it.

Mo: Significant compression.

Mike: Doesn't matter which document, willing to punt it.

Ian: Sync with Alan.

Repetition of AUTH TOKEN parameter #996

Ian: Can you have the same type and value twice?

Will: Token roll over is the reason for sending two different tokens
with differnt values but same type.

Agreement that sending two different tokens of the same type is ok.

What about duplicating the same token.

Victor: Reminds me of Set-Cookie header.

Luke: No one is going to check this. So say nothing

Mike Bishop: Noted that QUIC states that the peer MAY close the
connection if it detects.

Ian: MUST NOT be identical, MAY enforce?

Disallow USE_ALIAS and DELETE auth token in CLIENT_SETUP

Ian: we allow the client to register tokens without knowing the server's
cache size.

Ian: Could remember server's cache size, fail if it was wrong.

Martin: Shouldn't send tokens in 0-RTT.

Will: You would send a token in CLIENT_SETUP and try to set an alias.
Would know if it wasn't stored.

Cullen: Who would even pass a token in setup instead of each subscribe?

Ian: Some people will auth on setup and never auth again. Depends on the
use case.

Martin: Might introduce another RTT if the alias wasn't accepted.

Victor: CLIENT_SETUP in ALPN would fix this.

Martin: Do you get an error or fatal error if you register over the max
size?

Ian: Going to use Alan's comment. Agree that it's fatal to use
USE_ALIAS in CLIENT_SETUP.

Martin: There's currently an exception for CLIENT_SETUP in the draft.

(no conclusion)

Cullen: Maybe the current draft is just good enough.

Delivery Timeout, Datagrams, and Caching (#1103)

Ian: Are publishers supposed to retransmit datagrams?

Mo: Application chose datagrams for a reason.

Will+Christian: Should just send datagrams once.

Ian: Relays are going to retransmit datagrams anyway.

Luke: Use-case different viewers with different target latencies.

Mo: Should just do a FETCH to do an application retransmit.

Martin: Not possible for many QUIC stacks.

Mo: Delivery timeout means delivery to QUIC stack.

Luke: Can't prohibit publisher from retransmitting.

Conclusion: No mention in the draft, don't prohibit it either.

Ian: jk text: SHOULD NOT retransit

Delivery Timeout Mix and Match

Ian: Why is forwarding preference per track and not per object. Will it
break it we allow both datagrams and streams.

Mo: I thought you could do this.

(conclusion: different subgroups can use different modes, same subgroup
cannot)

Martin: Datagrams using subgroup ID == object ID won't work any longer.

Victor: Bitflag indicating if subgroup exists, defaults to zero.

Martin: Have to add a way to encode the subgroup for datagrams.

Elaborate on the role of the original publisher

Ian: Editorial.

Martin: Parked until Mo's thing to nuke multi-publisher.

Will: Wants multi-publisher for redundancy.

Martin: Wants to ban uncoordinated publishers.

Will: Could we make group IDs monotonically increase?

Should sending GOAWAY also block SUBSCRIBE

Victor: Current text says SHOULD NOT send new requests.

Martin: Seems dumb.

Luke: Original intent was to allow connection usage while reconnecting.

HTTP: Sends max request ID, connection unusable after GOAWAY.

Ian: Should be max Request ID in GOAWAY like HTTP.

Whiteboard:
Client SHOULD NOT SUBSCRIBE after receiving GOAWAY
Client SHOULD NOT PUBLISH after receiving GOAWAY
Server ? SUBSCRIBE after sending GOAWAY
Server ? PUBLISH after sending GOAWAY

Meeting Concluded