MOQ WG Interim Meeting Minutes — 12 June 2026 (Day 2)

Date: 12 June 2026
Location: Cloudflare offices (London), hybrid via MeetEcho
Chairs: Magnus Westerlund, Martin Duke

Attendees

Morning session (29)

Yu You, Ryan McCartney, Michal Hošna, Gwendal Simon, Cullen Jennings, Martin Duke, Christoph Neumann, Mike English, Magnus Westerlund, Alan Frindell, Asad Saeed, Zafer Gürel, Adrian Roe, Manish, Steven, Brett Mertens, Jordi Cenzano, Kevin McMenamy, Alessandro Amirante, Victor Vasiliev, Aman Sharma, Leto Baxevanaki, Tongyu Dai, Mo Zanaty, Suhas Nandakumar, Will Law, Ali Begen, Torbjörn Einarsson, Ian Swett

Afternoon session (26)

Martin Duke, Magnus Westerlund, Gwendal Simon, Tongyu Dai, Yu You, Giovanni Marzot, Cullen Jennings, Torbjörn Einarsson, Suhas Nandakumar, Steven, Alessandro Amirante, Jordi Cenzano, Asad Saeed, Brett Mertens, Mo Zanaty, Alan Frindell, Victor Vasiliev, Aman Sharma, Adrian Roe, Ian Swett, Thibault Meunier, Michal Hošna, Mike English, Leto Baxevanaki, Will Law, Ryan McCartney

---

Administrivia (0930–0945)

• Note Well reminder for new attendees.
• MeetEcho logistics: log in for blue sheets, queue management, and chat.
• Agenda overview: Top-N/DTS/switch work first, then MOQT parking lot issues, lunch break, more MOQT issues, then MSF/CMSF and other adopted drafts.
• Hard stop at 14:30 due to editor departure; remainder for adopted drafts.
• Draft 18 remains interop target for Vienna.

---

Interop Report (Mike English)

Summary: Mike presented the latest automated interop test runner results targeting draft-18. 16 tests ran at target. Still some setup-related failures (not protocol-related). A wiki page was created for ad-hoc interop reports in addition to the automated runner.

Discussion:
- Ali Begen: should also think about testing sensitive media quality (seeing the video), not just signaling.
- Cullen Jennings: noted ~50-70 features in draft-18; need to identify them and track coverage.
- The automated test runner currently has only a handful of specified test cases; needs expansion to ~70.
- Limitation: no good way to drive web-based clients in the interop program currently.

Decisions:
- Keep Draft 18 as interop target for Vienna.
- Expand test case coverage systematically (prioritize highest-value tests first).

---

SWITCH/DTS Implementation Lessons (Ali Begen / Ollie)

Summary: Ali (Ozyegin University) presented experimental results comparing subscriber-initiated track switching methods and DTS (relay-executed switching).

Methods compared:

1. Forward state toggling: Subscribe to both tracks, toggle forward 0/1 at switch time. 3 control messages. Risk: gaps or duplicate data.
2. Joining Fetch: Use fetch for past groups. 3-5 control messages. Some corner cases.
3. Switch message (atomic): Single control message telling relay to switch. 1 control message. Zero gaps, zero redundant traffic target.

Key results:

• Track alignment scenario (unlimited bandwidth): Switch message has least delay and no redundant traffic. Forward toggling has ~0.5s delay. Joining fetch similar delay but skips one group.
• Bandwidth-limited scenario (3 Mbps pipe, downshifting from 4 Mbps track): All methods show significant delay (5-7 seconds for forward toggling). Switch message still best but still has delay at 3 Mbps.
• Downstream delay scenario: Switch message wins because it requires only 1 RTT. Forward toggling affected 1 RTT, joining fetch affected 1-2 RTTs.

DTS results:

• Relay uses number of active send streams (depth) as congestion signal — no bandwidth measurement needed.
• Upshift after N consecutive clean groups; downshift when depth increases; discard when latency budget exceeded.
• Simple but effective; follows latency budget well.

Discussion:
- Cullen Jennings: important caveat about relay implementation — whether data is queued into QUIC stack (hard to remove) vs. only handed to stack when cwin opens (can reprioritize). This dramatically changes results. The draft intentionally doesn't mandate one approach.
- Victor Vasiliev: QUIC has RESET_STREAM but no API to yank data back from stack.
- Will Law: physics problem — can only put 3 Mbps into a 3 Mbps pipe regardless of QUIC trickery.
- Yu You: also experimenting with this; wants specified design patterns.

---

Top Tracks Filter / Top-N Issues (Mo Zanaty + Cullen Jennings)

Reference: https://github.com/moq-wg/moq-transport/pull/1518

Rename and Status

Filter renamed from "Track Filter" to "Top Tracks Filter" to reduce confusion. Will make a new PR to separate it out (and if needed, a new draft).

Use Cases

• Active speakers in meetings / most active speakers
• Security cameras: top 16 by activity/suspicious incidents
• eSports: top players by score
• Viral video feeds: top N most upvoted
• Markets: top bid in auctions
• ABR: give me the top quality track within my bandwidth

Design (one-pager)

• Setup option to enable (default 0 = no support)
• Parameter: top_tracks_filter with property type and N (number of top tracks)
• State machine: Unknown → Newly Selected → Selected → Deselected (LRU cache) → Evicted (publish done)
• Relay subscribes to all publishers in namespace; only forwards objects from top-N tracks to subscribers
• Publisher declares timeout (how long metric can be stale before eviction)
• Selection/deselection via publish/forward-zero/publish-done control messages

Discussion:

• Ian Swett: concern about relay controlling forward state (normally subscriber controls it). Proposed splitting subscriber-forward and publisher-forward into separate bits.
• Will Law: subscriber opted in to top-N filter, so both parties understand what's happening.
• Alan Frindell: cool feature, people will use it. Concern about maturity — would feel more comfortable with a second independent implementer with a slightly different use case. Willing to accept it given the spec is small and you can turn it off.
• Cullen Jennings: this use case predates the working group charter. Far more mature than proposals to remove fetch. Critical for media vendors to move from SFUs to MOQ relays.
• Suhas Nandakumar: Zoom is the biggest WebEx user and is following this even if not present. This is the differentiation MOQ provides over HLS/DASH.
• Kevin (Cisco, remote): design is sound, takes into account all the real-world factors from decades of interactive communication technology.

Performance Data (Cullen)

• Algorithm: scoreboard of top N+X tracks, recomputed every 50ms, lock-free reads, lock-free insertions.
• MonkX relay: <2% CPU overhead, <300 bytes additional state per subscriber.
• MonkRS relay: similarly negligible overhead.
• Memory: drops in the bucket compared to QUIC stack per-connection overhead.
• Tested at 8000 publishers (8 cores × 1000): still only 2% CPU.
• Scales well through relay mesh: top-N propagates upstream, dramatically reducing inter-relay traffic.

Concerns and Responses:

• Maturity: Nearly a year of design iterations, 3 implementations running.
• Complexity: Spec text is small; runtime complexity dominated by QUIC/crypto operations.
• DDoS: Asymmetric by design (high ingress, low egress). Relay can impose limits (namespace too large, conflicting filters).
• Extensibility: Currently specified as an extension. Could move into MOQT core if consensus forms. Alan to file issue if extensibility model is insufficient.

Decision: Work continues as extension. Alan's remaining concerns (second independent implementation) noted. Performance data shows negligible overhead.

---

MOQT Parking Lot — Continued Issues (Alan Frindell + Ian Swett)

PR #1642 Path Forward (Fill Fetch)

Alan summarized planned changes to PR #1642 based on day 1 discussion:

1. Remove current group delivery (follow-up PR later)
2. Relative previous fill: redefine so zero = current group, one = group before current
3. Remove absolute start filter and absolute range filter (keep absolute start fill and absolute range fill only)
4. Add separate parameter block for fill-specific parameters (from Victor's idea)
5. Simplify prioritization: fill group order dictates priority (ascending = fill higher priority; descending = live higher priority)
6. Standalone fetch NOT removed immediately (follow-up PR)

Discussion:
- Victor Vasiliev: this resolves all his issues.
- Ian Swett: only one fill parameter per request (can do request update for different fills later).
- Gwendal Simon: need to clarify error handling between the two legs (fill and live).
- Alan: target is Draft 19. Design PRs need to be open by June 22 (two-week review period).

Decision: Consensus on the path forward. PRs to be written immediately.

---

switch_from PR

Alan: will create two PRs — one for hard mode (basic mechanism + hard), one for soft mode. Changed to an enum to allow future modes.

Discussion:
- Cullen Jennings: wants hard only first, land it fast so Ali can experiment. Soft might need different design.
- Alan: agrees hard can land immediately. Soft may take longer.
- Ali Begen: will use hard mode for experimentation, report back.

Decision: Two PRs: hard mode (land immediately), soft mode (separate, more discussion needed). Enum allows future modes.

---

Issue #1316: VOD Support

Discussion: 1642 makes VOD slightly better (subscribe + request update for ranges). Some wanted pacing/subscribe semantics for VOD which is a different problem. Not in scope for now.

Decision: Close. Add editorial note about how to do VOD with fill fetch. Broader VOD-over-subscribe would be an extension/individual draft.

---

Issue #1270: Publisher Priority Updates

Discussion: Can't change track properties (immutable). Object properties can override per-object. For audio, priority changes frequently and matters. Proposal: use data plane signaling (object property) that's "sticky" within a group. Mo wants to keep the ability. Alan: disagrees with making track properties mutable but acknowledges audio use case.

Decision: Track properties stay immutable. Interested parties to write a PR for a data-plane mechanism to update priority (possibly sticky object property). Mike volunteered to work on it with Cullen.

---

Issue #1063: Rate Limiting REQUEST_UPDATE

Discussion: PR #1613 proposes MAX_REQUEST_UPDATES setup option (default infinity after debate). Limits outstanding unacknowledged request updates per subscription. Coalescing mitigates the attack surface. Delivery timeout updates could be expensive (iterating all streams). Fill spawning is also potentially expensive.

• Cullen Jennings: authorization and tokens are the real solution to DDoS, not per-message rate limits.
• Alan: agrees auth helps but this is defense-in-depth; HTTP rapid reset showed these attacks are real.
• Ian Swett: FIFO processing + natural aggregation provides some protection; this PR adds a belt to the suspenders.

Decision: Land PR #1613 with default infinity. Simple check, doesn't hurt, provides a knob for relays that want it.

---

Issue #869: Resource Consumption of a Subscription

Discussion: PR #1591 provides byte/stream limits per subscription. Mixed enthusiasm. Related to DDoS design team work. Some want it for relay fairness (limit one subscription from consuming all resources). Victor: subscriptions are implicitly flow-controlled by delivery timeout/too-far-behind.

Decision: Defer to next virtual interim. Ian to update PR and present in more detail. May move to extension if no stronger appetite emerges.

---

Issue #974: Upstream Delivery Timeouts

Decision: Close with no action. Would require time synchronization which is "impossible to get agreement on at IETF" despite being trivial in practice. Timestamp extension may provide a better path.

---

Issue #969: Authorization Alias → Extension

Discussion: Show of hands: very few plan to implement auth alias compression. Strong case to remove from core:
- Interest low; subscriptions are long-lived (less repetition than HTTP)
- Bidi streams reduced effectiveness without QPACK-like machinery
- MOQPACK draft (Alan) provides a better comprehensive solution
- Having it in core draws scrutiny during endgame

Counter (Will Law): ABR switching means subscriptions may only last seconds; tokens are 10-100x larger than messages. Still need compression eventually.

Decision: Temporary repark with countdown. If nobody produces data showing it's essential before working group last call preparation (~2 months), it comes out. Suhas committed to implementing auth and evaluating whether compression is needed.

---

Issue #899: Multiple Ranges in FETCH

Discussion: Now that we have filters (and specifically if we adopt the location filter with multiple ranges), you can express disjoint ranges in a single fetch.

Decision: Support multiple ranges via location filter. They come on one stream (delta-encoded, so must be in order, no overlaps). Separate fetches still available if you want multiple streams.

---

Issue #881: Renumber Everything

Decision: Reparked until closer to done. Will renumber all enums contiguously starting from zero.

---

Issue #273: Reason Phrases

Discussion: Pro: improves developer experience. Con: UTF-8 without full internationalization will cause ISG pushback; security concerns with bidirectional text.

• Cullen Jennings: wants to remove them eventually; proposes more granular error codes instead.
• Alan: proposed adding specific error code numbers for every "protocol violation" in the spec (~50 places).
• Will Law: if we're going to have rich feedback, just leave reason phrases as-is.
• Concrete proposal: leave in draft, make a call before last call whether to remove.

Decision: Leave as-is for now. Decision deferred to pre-last-call review. Consider switching to binary data to avoid UTF-8 normalization issues.

---

Issue #475: Timestamps

Discussion: Use cases: audio/video sync, multi-publisher sync, delivery timeout improvement, DTS group alignment. Time sync across publishers is hard but O(Xms) accuracy is sufficient for delivery. DTS uses group alignment (doesn't need timestamps).

Proposal: track property for absolute timestamp, object property for relative timestamp, plus a "sync field" concept to associate tracks that should be delivered in sync.

• Alan: this was always wanted for priority (don't let one track get too far ahead). Extension is the right path.
• Cullen Jennings: wants NTP absolute timestamp for debugging/metrics. Layer violation but worth it.
• Victor: layer violation concern — applications define their own timestamps. Better to have a generic "sync field" that points to any existing field.
• Jordi Cenzano: RTP carries timestamp for this; MSF has media timeline. Different applications need different timestamps.

Decision: Extension draft. Lots of interest but too many different timestamp types to standardize one in core. Will likely involve a "sync field" concept for delivery prioritization. Separate from media-level timestamps.

---

MSF/CMSF (Will Law)

Reference: https://datatracker.ietf.org/doc/draft-ietf-moq-msf/, https://datatracker.ietf.org/doc/draft-ietf-moq-cmsf/

MSF Draft-01 Updates

Will highlighted major additions in draft-01: end-to-end encryption, log/metrics tracks, media timeline template, URL schema with fragment parameters, variable subscription scheme, token-based auth (Privacy Pass + CAT), payload compression (gzip), restructured catalog fields, delta updates now ordered. Torbjörn Einarsson (Eyevinn) built a validator tool for catalogs.

Issues Discussed:

Updating init data mid-track:
- Three options: put in catalog (static), track property, or object property (dynamic).
- Victor: prefer object property (self-initializing sequences / IDR + in-band init). Simple, no cross-track coordination.
- Resolution: Create PR with three methods. Use object property for dynamic cases, catalog for static. No objections.

Event timeline track header:
- Proposal to add a header object for initialization data in event timeline tracks.
- Victor/Gwendal: use a track property instead of a header-per-group.
- Resolution: Use track property for event timeline header data.

URL fragment identifier (MSF vs CMSF prefix):
- Resolution: Just use msf prefix for everything. CMSF is an extension of MSF; catalog tells you what's inside.

Object-to-stream mapping:
- Question: should MSF specify how media maps to MOQT subgroups/streams?
- Discussion: useful for player builders to know what they're getting (whole GOP vs. one frame per stream). But terminology needs fixing (use subgroups, not "streams").
- Resolution: Add a table/enum. Rewrite in terms of MOQT subgroups. Container-format-specific details belong in LOC/CMSF, not MSF.

Catalog track naming (must it be "catalog"?):
- Discussion: Luke wanted flexibility. Arguments for relaxing to SHOULD.
- Resolution: No consensus to change. Leave as-is (MUST be "catalog"). Discuss further on issue tracker.

Track property mutability within catalog:
- Resolution: Allow updates via new delta update verb ("update"). Add to PR.

Delta update mechanism (JSON Merge Patch?):
- Strong opposition to JSON Patch or JSON Merge Patch (too heavy, array limitations).
- Resolution: Keep current custom mechanism. Custom data that changes frequently should go in a separate data track, not the catalog.

LockMaf compression (CMAF over LOC):
- iBIN's delta-encoding scheme for CMAF audio packaging: 20-30% bandwidth savings.
- Resolution: Write PR to incorporate into CMSF draft. Check IPR (current implementation is MIT licensed). Need independent implementation.

---

Secure Objects (Cullen Jennings)

Reference: https://datatracker.ietf.org/doc/draft-ietf-moq-secure-objects/

Cullen gave a rapid overview of recent changes:
- Fan-out attack analysis (100K subscribers = 100K parallel crypto computations)
- Key length adjustments (no practical changes for normal use)
- Canonicalization: all integers re-canonicalized as 64-bit for crypto (avoids relay re-encoding bugs)
- Relays MUST NOT change publisher priority (thrown into identity protection)
- Object IDs limited to 32 bits; Group IDs remain full 64-bit
- Padding extension added (round up to power of 2) for traffic analysis resistance
- Track properties NOT protected (control plane, not data plane) — put sensitive data in payload
- Test vectors added

Decision: Draft is close to ready for working group last call. Requested thorough review with "is this ready for last call?" mindset. Will coordinate with chairs on timing relative to MOQT.

---

Privacy Pass Authorization (Suhas Nandakumar)

Reference: https://datatracker.ietf.org/doc/draft-ietf-moq-privacy-pass-auth/

Suhas presented a working prototype demonstrating three authorization flows:
1. Guest flow: Anonymous user gets time-scoped CAT token for public rooms (read-only)
2. IDP-backed flow: User authenticates with Google/corporate IDP, token service mints CAT token with appropriate scopes
3. Privacy Pass flow: Relay doesn't learn user identity; IDP doesn't learn which room. Requires challenge mechanism (relay → client → attester → client → relay).

Built using: CAT token library, TypeScript client, MOQ WebCast, MockRS (with auth hook), Privacy Pass client library.

Key finding: Need a challenge mechanism in MOQT (relay sends challenge, client responds with token). Not the same as error payload — needs proper auth design team work.

Decision: Authorization mechanisms heading in right direction. Both CAT and Privacy Pass flows work. Auth design team needed to resolve:
- Challenge mechanism for Privacy Pass
- Aggregated subscription authorization (two subscribers with different tokens)
- Relay-to-relay authorization

---

Next Interim Planning

• Next virtual interims in coming weeks (dates per earlier schedule).
• Next hybrid interim: week of October 12, 2026. Several North American venues volunteered. Chairs to confirm availability and poll.

---

Summary of Action Items

#	Action	Owner
1	PR #1642 updates (remove current group, add fill params, etc.) — open by June 22	Alan Frindell
2	switch_from PR: hard mode (land immediately)	Suhas Nandakumar
3	switch_from PR: soft mode (separate)	Suhas Nandakumar
4	Top Tracks Filter: continue as extension, seek second implementer	Mo Zanaty, Cullen Jennings
5	File issue on MOQT extensibility if insufficient	Alan Frindell
6	Priority update mechanism PR (data plane, sticky object property)	Mike English, Cullen Jennings
7	Land PR #1613 (MAX_REQUEST_UPDATES, default infinity)	Ian Swett
8	Multiple ranges in location filter design	Victor Vasiliev, Ian Swett
9	Timestamp/sync extension draft	Interested participants
10	Auth design team formation	Chairs
11	Evaluate auth alias compression need (deadline: before last call prep)	Suhas Nandakumar
12	Secure Objects: thorough review for WGLC readiness	All
13	MSF: init data PR, LockMaf incorporation PR	Will Law, Torbjörn Einarsson
14	Resource consumption (#869): present at next virtual interim	Ian Swett
15	Coordinate padding extension between Secure Objects and YouTube impl	Cullen Jennings, Victor Vasiliev