MOQ WG Interim Meeting Minutes — 11 June 2026

Date: 11 June 2026
Location: Cloudflare offices (London), hybrid via MeetEcho
Chairs: Magnus Westerlund, Martin Duke
Note-takers: (from transcript)

Attendees (33)

Renan Dincer, Manish, Alessandro Amirante, Alan Frindell, Martin Duke, Magnus Westerlund, Ryan McCartney, Gwendal Simon, Zafer Gürel, Christoph Neumann, Rich Logan, Yixin Lin, Tobia Castaldi, Steven, Asad Saeed, Jordi Cenzano, Dinesh Adhithya, Lars Eggert, Michal Hošna, Mike English, Ian Swett, Tongyu Dai, Leto Baxevanaki, Yu You, Suhas Nandakumar, Aman Sharma, Ali Begen, Cullen Jennings, Piers O'Hanlon, Victor Vasiliev, Mo Zanaty, Torbjörn Einarsson, Will Law

---

Administrivia (0930–0945)

• Welcome and introductions around the table.
• IPR reminder (Note Well).
• First hybrid interim using MeetEcho support; attendees asked to log into MeetEcho for blue sheets, queue management, and chat.
• Queue management: in-room conversation kept naturalistic; remote participants use the raise-hand button; chairs will slide them in when appropriate.
• Remote participants reminded about latency on unmute and asked to use headsets for echo cancellation.
• Agenda overview: focus is on MOQT issues with aspiration for last call in Vienna.
• Fire drill scheduled at 10:15 — used as break opportunity.
• Catered lunch at 11:45, with Tongyu Dai demo of a diagnostic tool (optional attendance).
• Next hybrid interim planning in September/early October.
• Mike English DOS design team readout noted for end of day.
• Agenda bashed: order adjusted — Mo's Object Range Filters moved before Concurrent Subscribe (Ian not yet ready). Joining Fetch (Alan + Mo) follows after the break.

Upcoming dates noted:

• Two virtual interims proposed (both Mondays at 16:30 UTC / 09:30 Pacific).
• Three sessions requested for IETF Vienna.
• Draft deadline reminder given (odd-numbered draft expected incorporating interim resolutions).

---

Object Range Filters (Mo Zanaty) — PR #1518

Reference: https://github.com/moq-wg/moq-transport/pull/1518 (originally PR #1401)

Summary

Mo presented the recently adopted Object Range Filters design (PR #1518). Key design points:

• Setup option: max_filter_ranges (default zero = opt-in) limits total number of ranges across all filter types per subscription/fetch.
• Filter parameters can appear in: Subscribe, Subscribe Tracks, Request Update, Publish OK, and Fetch.
• Four filter types: Object ID, Subgroup, Priority, and Property filters.
• Set concept: Allows a relay to aggregate filters from different downstream subscribers into multiple sets (items within a set are ANDed; different sets are ORed). This avoids the need for multiple subscriptions to the same track.
• Delta encoding used for wire efficiency.
• Inclusive ranges support all relational operations (equal, less-than, greater-than, between, not-equal) via set combinations.

Issue 1: Property Filter on Publish Messages

The property filter can filter both object properties and track properties. When used in Subscribe Tracks with a track property, it filters the Publish message itself — if the track property doesn't match, no Publish (and therefore no objects) is sent.

• Alan had initially missed this but confirmed the text is clear.
• Suhas raised a subtlety: if a property is not on the track but appears on a later object, the track is never seen by the subscriber. This is intentional and understood.
• Discussion about the behavioral difference vs. subscribing directly (where you'd get objects and filter at object level).

Decision: Property filter behavior on Publish messages is accepted as-is. No controversy; considered a logical consequence of track properties being added after filters were designed.

Issue 2: Remove Object ID Filter?

Mo proposed removing the Object ID filter since its primary use case (keyframe scrubbing via object ID 0) is not guaranteed to work (leading pictures, temporal scalability structures). Alternatives exist: separate subgroups for keyframes, or marking keyframes with a property.

Discussion:
- Victor Vasiliev raised that it can still be useful even if not 100% keyframe-accurate; 98% of the time object 0 is a keyframe (true for MSF's adopted streaming format).
- Suhas Nandakumar: objects are the atomic unit of transmission; filtering them at the object ID level is equivalent in cost to filtering by property.
- Ali Begen: catalog can indicate what object 0 contains; escape hatch exists for marking other objects (e.g., SCTE markers at specific object IDs).
- Multiple people raised hands in favor of keeping it.
- Martin Duke (as individual): noted preference against removing, particularly since alternative 1 (subgroups for keyframes) conflicts with expressing dependencies.

Decision: Keep the Object ID filter. It has utility, is already in the PR, and there is no consensus to remove it.

Issue 3: Re-add Location Filter?

The location filter was in the original PR #1401 but removed from #1518 to simplify the diff. Mo recommended re-adding it as it:
- Replaces the growing enum of subscription filter types with a simple range-based approach.
- Supports both relative and absolute location filtering.
- Aligns with all other filter types in syntax.
- Simplifies what the app needs to express (just a range of objects).

Discussion:
- Victor Vasiliev: agrees with the direction but wants to think through intersection with Joining Fetch and Fetch semantics. Also: please do not put it in the same PR as the other filters.
- Suhas Nandakumar: supports it; group ID and object ID are core identifiers and this enables filtering on them.
- Cullen Jennings: concern about subscribe historically ending on group boundaries for stream termination reasons; location filter flattens that. Noted edge cases with FIN semantics when a filter ends mid-group.
- Ian Swett: previously didn't have end-of-group marking, but now we do (FIN); the old reasons for not doing this are resolved.
- Victor: reliable RESET could also solve the edge case.

Decision: Consensus to produce a PR re-adding the location filter (separate from #1518). Acknowledged it would replace subscription filter enums (not add on top). Further review needed on interaction with Fetch semantics.

Top-N / Track Filter Status

• Current status: all filters including property filter are proceeding into MOQT (PR #1518).
• Top-N filter current status is "extension" — not in the core PR.
• More data expected from Friday discussions before final determination.

---

Break (1015–1030) — Fire Drill

---

Joining Fetch / Fill Fetch (Alan Frindell + Mo Zanaty) — PR #1642

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

Background

Survey results presented:
- Nobody said Joining Fetch failed functionally.
- 6/9 preferred current design (including 2 who don't use it).
- But 8/12 said they don't like it or it's not working for them.
- Majority wanted more time to get it right.
- If changing: must rip out Joining Fetch entirely (keep functionality, don't add parallel mechanism).
- Nobody demanded removing fetch data plane entirely.

Part 1: Current Group Delivery

Proposal: Objects in the current group (the group spanning the largest object / live edge) can be delivered via subscribe streams (subgroups/datagrams) rather than requiring a separate fetch. The publisher serves from the beginning of the group from cache or upstream subscription.

Happy paths:
- Relay has no upstream subscription → issues one with current group, relays directly.
- Everything in current group already in cache → serve directly.
- Cache incomplete but upstream subscription started before current group → missing objects still in flight, can start delivering.

Unhappy paths:
- Upstream subscription started mid-group (avoidable by subscribing on group boundaries).
- Group too large for cache.
- Cache eviction creating "swiss cheese" gaps.

Failure handling: PR adds a reset stream code for "current group unavailable"; subscribe can simply move on to the next group.

Discussion:

• Ali Begen: wants not just current group but also prior groups (e.g., OTT live streaming requires groups behind). Current group alone serves only real-time use cases.
• Alan: the second half (fill fetch) addresses groups before current; the distinction is about data plane delivery, not about what you can ask for.
• Cullen Jennings: lengthy analysis of priority/congestion issues. Bursting 11A (first half of current group) causes fake congestion; QUIC CC interprets it as file transfer mode; subgroup priority reordering causes object misordering that delays playout buffer. Works fine with single subgroup but problematic with multiple subgroups.
• Suhas Nandakumar: concern about missing subgroups in 11A leading to degraded experience with no recovery mechanism (unlike Joining Fetch which would go upstream).
• Ian Swett: supports it for headline-blocking improvements and latency benefits; extra complexity acceptable given performance gains.
• Victor Vasiliev: if 11A not available, 11B blocked (can't send without front of subgroups); 12 goes first naturally — addresses the priority concern somewhat.
• Alan: proposed giving the app explicit control — deliver current group via subscribe streams, fill fetch streams, or not at all (toggle per subscriber).

Decision: No formal consensus. Mixed sentiment — some strong support, some skepticism. People need time to digest. Will revisit temperature check the next morning (parking lot). Action: identify who really needs current group delivery and have focused conversations about the edge cases.

Part 2: Fill Fetch (Expanding Subscribe Capabilities)

Proposal: Subscribe can deliver groups earlier than current via a "fill fetch stream" (fetch-formatted stream opened by the publisher in response to a subscribe/request update that includes a past range).

Key properties:
- Joining Fetch text is removed from the draft.
- Each request update changing the fill range spawns a new fill fetch stream.
- Subscription to VOD (entirely past ranges) becomes possible — slightly nicer than standalone fetch (no track name retransmission, shared state, track properties sent once).
- switch_from parameter enables clean client-side ABR track switching.

Shared vs. unique parameters:
- Subscribe priority, auth token: shared between subscribe and fill fetch.
- Group order: three modes (both ascending, both descending, fill-descending/sub-ascending).
- Filters: may need to be unique per side (e.g., subgroup filter only on fill fetch for base-layer-only backfill).
- Proposal for separate parameter sections rather than nested blobs.

Coupling with subscribe:
- Forward zero cancels all fills.
- Canceling the subscription cancels all fills.
- Can cancel fill independently without canceling subscription.
- Fill timeout vs. delivery timeout apply to different parts.

Things lost vs. Joining Fetch:
- Can't set different numeric subscriber priority on subscribe vs. fetch (tiebreaker is group order only). Acknowledged this could be fixed.
- Can't do "outside-in" group order.
- No separate control message for fill errors (errors use reset stream, unknown range markers, or request error which kills the subscription).

Discussion:

• Wendell (Gwendal Simon): supports; solves client-side ABR switch-from use case cleanly; important for relay flow chart (which he analyzed — works end-to-end).
• Cullen Jennings: conceptually similar to joining fetch; need to nail down priority, error handling, and relay chain behavior; need concrete use cases written down; not opposed but details matter.
• Victor Vasiliev: removes the biggest hazard of joining fetch (race condition between join location recording and subscribe/fetch timing); definitely requires focused design team time.
• Mike English: keeping standalone fetch means you always have fallback for other backfill needs; joining fetch was always a pipeline optimization.
• Suhas Nandakumar: supports removing fetch and joining fetch; fill fetch is a better mechanism; fetch by itself has holes and inefficiencies.
• Ali Begen: doesn't think this solves use cases not already solved today; would rather prioritize getting existing draft done before adding this.

Decision: Strong positive sentiment toward the direction of PR #1642 (fill fetch replacing joining fetch). No one argued it's a fundamentally bad idea. Concerns are about details (shared vs. unique parameters, priority control, error reporting, relay behavior). Action items:
- Focused design team work on the detailed edge cases (Victor's four issues, Gwendal's flow chart gaps).
- If convergence takes too long, open up all knobs and land something; iterate via follow-up issues.
- Relationship between current group delivery and fill fetch is separable; fill fetch does not require current group change.

---

Other MOQT Issues (Alan Frindell + Ian Swett)

Slides: slides-interim-2026-moq-08-sessa-moqt-issues-london-04 (35 slides)

The editors presented open MOQT issues from the slide deck "MOQT Issues London." Only a subset of the slides were discussed on day 1. The remainder were deferred to day 2.

---

Issue #1637: What does MOQT do without bidi stream credit?

Summary: SUBSCRIBE_NAMESPACE, SUBSCRIBE_TRACKS, PUBLISH_NAMESPACE, FETCH, TRACK_STATUS clearly require retry by the requester. Previously had REQUEST_BLOCKED, now have QUIC STREAMS_BLOCKED.

Questions:
- App responsibility or MOQT responsibility? Is it an API question?
- HTTP often opens another session — good enough or anti-pattern?
- What is the expected relay behavior if a request doesn't have credit?
- SUBSCRIBE/PUBLISH are different: if PUBLISH doesn't have credit, can replace with SUBSCRIBE and vice versa

Discussion:

• Opening another session is discouraged (IETF principle since HTTP/1.1); can't have request dependencies across sessions; servers can't open new sessions.
• Most QUIC stacks grant credit automatically near the watermark, but there's a hard concurrency limit.
• There will always be cases where the relay must give up (e.g., client allows 10 streams, all in use, 11th subscriber arrives — relay is blocked on the client, downstream subscriber has no visibility into this).
• Cullen Jennings: if using streams as the DDoS limiting mechanism (works for HTTP), it may not work here due to relay chains.
• The subscriber already has a timeout on subscribe; if no subscribe OK comes within timeout, it cancels regardless of reason.

Decision: Alan or Ian will write a PR proposing request_error for stream credit exhaustion. This is the simplest solution since max-pending-requests exhaustion must produce an error anyway. Additional timeout/queuing mechanisms can be added later if needed.

---

Issue #1637 (cont'd): Publish Blocked / Publish Skipped

Summary: PUBLISH_BLOCKED exists for namespace streams only. What is expected behavior when receiving it? Options: add stream credit, or send SUBSCRIBE (but what if that's also blocked?).

Discussion:

• Ian Swett: doesn't want to implement queuing of blocked publishes and later unblocking them.
• The message should be renamed to publish_skipped — decoupled from flow control, covers resource management (e.g., relay intentionally not using all bidi streams for this subscribe_tracks).
• Cullen Jennings: client needs to understand limits; subscribe_tracks_ok should indicate max tracks or similar.
• Consensus that it should be informational (not an error) — subscriber can then decide to send a direct subscribe if it wants the track.

Decision:
- Rename publish_blocked to publish_skipped.
- Ian Swett will write this up.

---

Catered Lunch + Tongyu Dai Demo (1145–1300)

Tongyu Dai presented a 10-minute demo of a diagnostic tool for MOQT (described as "Wireshark for MOQ"). Attendance optional; sidebar conversations encouraged.

---

Concurrent Subscribe (Alan) — Issue #1633

Reference: https://github.com/moq-wg/moq-transport/issues/1633

Summary: Discussion on allowing multiple subscriptions to the same track within a single session (currently forbidden). The key concern is what happens with track aliases when overlapping subscriptions exist.

Discussion:

• Will Law: easier to do as a single union subscription rather than iterating through multiple subscriptions.
• Alan Frindell: if a subgroup matches both subscriptions, the publisher would open two separate streams with identical contents — bandwidth wasteful but makes it easier on the publisher/subscriber.
• Agreement that the reason to allow this is specifically for subscribe/unsubscribe racing — the subscriber should have already thrown away state with unsubscribe.
• Piers O'Hanlon: could imagine legitimate deduplication use cases.
• Conclusion: allow concurrent subscribe (option 1A from the issue), with the publisher choosing the alias. If the publisher picks the same alias, the subscriber suffers the consequences.

Decision: Allow concurrent subscribe with appropriate warning text in the draft about the risks of overlapping subscriptions and alias conflicts.

---

Request Ordering / switch_from (Alan)

Summary: Alan presented a proposal for atomic track switching via a new switch_from parameter in Subscribe/Request Update. This addresses use cases for video conference speaker swaps and client-side ABR switching.

Design:
- switch_from contains a Request ID referring to the track being switched from, plus mode bits (hard/soft) and a publish_done bit
- No race condition: both the subscription being switched from and the new one must already exist
- Location filter governs the start group for the new track
- Hard mode: immediately sets forward=0 on the suspended subscription
- Soft mode: sets end group of old subscription to (start group of new) minus one, draining to end of group
- Request OK signals when the switch has occurred

Discussion:

• Gwendal Simon: likes Cullen's suggestion of a mode that finishes the current group then stops (in between hard and soft); most cases work with this; needs to work with fill fetch for congestion scenarios.
• Cullen Jennings: hard mode alone is worth doing; agrees more modes may be needed but should be data-driven.
• Alan Frindell: agrees hard mode is worth doing; should move forward with at least hard mode.
• Ian Swett: hard mode would work well for most cases.
• Will Law: happy day cases are easy; edge cases need more work; maybe only need one mode.
• Piers O'Hanlon: question about perpetually unaligned groups; hard stop at next boundary works.
• Will Law (re: DTS): if switch_from can cleanly close old subscriptions, DTS could use it relay-to-upstream, making it bandwidth efficient with only one upstream active.
• Victor Vasiliev has a related PR that depends on #1642 (in his repo, not main).

Decision: Move forward with hard mode. Soft mode and additional modes need more reasoning through edge cases. Depends on PR #1642 (fill fetch) landing. Ollie to present experimental results tomorrow on the old switch proposal.

---

DOS Design Team Readout (Mike English) — draft-englishm-moq-relay-dos

Summary: Mike English presented the DoS design team document (informational, not normative). It covers resource protection issues for relays, subscribers, and publishers, separating data plane (transport concerns) from control plane. It compiles existing discussion into a standalone document.

Questions posed:
- Is it worth publishing as an informational RFC or just useful as reference during base spec work?
- Is there appetite to adopt as a working group document?
- Should it remain standalone or be merged into another document?

Discussion: Good number of people had read the document. Aiming for a -01 version by Vienna. General support for continuing the work.

---

Other MOQT Issues — Continued (Alan Frindell + Ian Swett)

After the DOS Design Team readout, the group returned to the MOQT issues slide deck for the remaining time.

---

Issue #1655: Tighter language around GOAWAYs on a request stream

Decision: Alan to make a more specific proposal.

---

Issue #1653: REQUEST_OK in response to REQUEST_UPDATE lacks Request ID

Discussion: Agreement that we can't limit outstanding REQUEST_UPDATEs. Long discussion about whether there are issues with reordering replies, or what it means to coalesce requests. Group is unclear about processing semantics.

Decision: Come back tomorrow.

---

Issue #1634: What semantics do FIN or RST on a request stream carry?

Discussion: Detailed discussion about the meaning of RST, STOP_SENDING, and FIN on request streams:
- RST and STOP_SENDING are both equivalent to unsubscribe/cancel — the stream is dead, no longer a control stream.
- FIN from the sender (subscriber) means "I'm not going to send any more request updates" — it is NOT a cancellation. The subscriber still wants responses. If they wanted to cancel, they have RST or STOP_SENDING.
- Analogy to HTTP: sending GET + FIN in the same flight is normal in H2/H3 and is not a cancellation.
- Track Status is a good example: send TRACK_STATUS + FIN in same flight, still want the answer.

Decision: For each request type, clarify which messages can immediately precede a FIN. Create a table of valid FIN-preceding messages for each stream type, for both ends.

---

Issue #1635: Should a subscriber treat FIN/RST on a bidi stream as equivalent to PUBLISH_DONE?

Discussion: If a publisher sends objects and then FIN without PUBLISH_DONE, the subscriber has no stream count and cannot safely determine it has received all data streams. PUBLISH_DONE carries metadata (status code, stream count) needed for clean state deletion.

Decision: PUBLISH_DONE MUST be sent before FIN. No recommendation on what the receiver should do if violated — it's a protocol violation, receiver can reset or close session at their discretion.

---

Issue #1643: Is it a request or session error to FIN a response bidi stream without a control message first?

Decision: MUST send something before a FIN (bare FIN without control message is an error).

---

Issue #1651: How does GROUP_ORDER interact with PUBLISH?

Discussion: For SUBSCRIBE, subscriber may specify group order; if not, publisher default is used. Cannot update via request update. For PUBLISH (unsolicited, not from subscribe_tracks), publisher has no context so must use its default. But the spec allows the subscriber to update group order via PUBLISH_OK — recreating the inconsistency we tried to avoid with subscribe.

Resolution:
- SUBSCRIBE: unchanged
- PUBLISH: cannot update group order via PUBLISH_OK; if PUBLISH is a response to SUBSCRIBE_TRACKS, use the group order from that message
- General principle adopted: SUBSCRIBE_TRACKS parameters serve as a proxy for any subscribe — they apply to publish tracks that originate from it

Decision: File a new issue making explicit that SUBSCRIBE_TRACKS parameters apply to PUBLISH tracks if not explicitly set. Remove group order from PUBLISH_OK. (Note: property filter behaves differently in SUBSCRIBE_TRACKS vs. SUBSCRIBE — it controls whether the track is published at all.)

---

Issue #1622: Request ID in GOAWAY isn't useful

Discussion: The only actionable use: upon receiving GOAWAY with a Request ID, you can immediately cancel requests with higher IDs without waiting for individual errors. But the timing advantage is minimal. Ian wants to remove Request ID entirely. Others noted the optimization of knowing "I promise I didn't touch requests higher than this" is not worth the complexity.

Decision: Remove Request ID from GOAWAY. It was only added in draft-18.

---

Issue #1644: Duplicate Track Properties on repeated SUBSCRIBE_OK / FETCH_OK

Discussion: Mo argued that FETCH should be done in the context of a subscribe where properties have already been sent once, eliminating duplication. If not, add a parameter (properties=0/1) to suppress delivery. Extended discussion on whether track properties are immutable: currently the draft allows them to change and even has text about updating the cache, but this was surprising to many. If properties are immutable per namespace+name for all time, then properties=0 is safe to use even with cached values from prior sessions.

Decision: Will try to make track properties immutable (per namespace+name). File issue for immutability change.

---

Issue #1636: Empty namespace clarification

Discussion: Current draft allows empty namespaces AND empty names. Analogous to "/" in HTTP being valid. The length is part of the serialization; zero-length is a valid key. Forcing one to be non-empty will cause problems — someone will want a use case for the other one being empty. Prefix matching still works correctly with empty prefixes (subscribe to empty prefix = subscribe to everything).

Decision: Close with no action, or add clarification that empty is explicitly allowed.

---

Issue #1628: Version negotiation for QMUX

Discussion: A PR exists with minimal text (sentence and a half). But QMUX itself is in a high-churn state and referencing it from MOQT is "playing with fire." The group is not trying to do MOQ over QMUX as a standard path right now. For interop, people can just coordinate via Slack.

Decision: Keep QMUX out of MOQT for now. Close all QMUX issues in the MOQT tracker.

---

Issue #1582: Caching and propagation of REQUEST_ERRORs

Decision: Receiver of a request MAY cache for up to the Retry Interval (which is basically a TTL). If the error is propagated downstream, any elapsed time should be subtracted from the Retry Interval. Some errors, like unauthorized, might not make sense to propagate downstream, because its the relay thats unauthorized, not the end subscriber.

---

Issue #1453: Send Rate parameter

Discussion: Previously discussed at 3/30/2026 interim. The group-pacing approach (time between groups) was the rough consensus. If groups are 2 seconds apart and you send them 1 second apart, you're sending at 2x encode rate — a limit directly controls delivery without the relay needing to know bitrate. Implementation concern: per-connection pacing is trivial (3 lines of code), per-subscription is much harder. Should be done in tandem with the broader bitrate effort (#1507).

Decision: Some participants will try to write this as an extension and perform experimentation with data.

---

Issue #1405: Single Object Subgroups don't need a Subgroup ID

Decision: Close the issue.

---

Issue #1352: SUBSCRIBE does not need a forward parameter if we have filters

Discussion: Mo commented that Forward is overloaded — it means different things in different places (pause, publisher self-mute, pre-warm cache). With filters, there are now multiple ways to block traffic (forward=0, location filter with null range, etc.). This is redundant, but forward=0 has advantages:
- Concise and well-understood pause/resume concept
- Relay can cheaply check "all subscribers forward=0" without evaluating filters
- Filters are optional; forward is always present
- Forward=0 has specific relay semantics (relay still subscribes upstream with forward=1 to pre-warm)

Counter: before forward existed, you'd set start group far out, which actually told the relay more information (how soon you'll join). The distance between largest object and subscriber start was more informative than binary on/off.

Will Law noted: forward=0 as a separate flag allows the relay to skip filter evaluation entirely.

Decision: If someone is sufficiently interested, write a PR — there are people who will review. Suhas volunteered to write the PR once Object Filters land. Can't land before filters anyway.

---

Issue #1507: Mechanism to get sender's bitrate

Discussion: Luke presented two parts:
1. Publisher periodically reports max connection bitrate to subscriber (so subscriber knows if upswitch is feasible). Without this, application-limited streams provide no signal about available bandwidth.
2. Subscriber requests sender to probe a higher target bitrate (padding/probing). Essential for ABR with big jumps — you need to know the network can handle it before switching. WebRTC does this routinely.

Strong interest from multiple participants (Will Law, Ali Begen, Mo, Suhas, Piers, Ian). Will Law suggested using object properties for (1) — subscriber sets reporting interval, publisher reports bitrate. For (2), Victor's .padding track or QUIC-layer probing.

Mo argued strongly this should be solved at the congestion control layer — both sides already compute throughput continuously. The problem is there's no direct conduit between sender and receiver congestion controllers today; need APIs from CC up through QUIC up through MOQ.

Alan suggested .session tracks for (1); (2) might be better at the QUIC layer. Luke noted QUIC stacks don't expose probing APIs today, so application-layer approach may be needed as fallback.

Anecdote: Luke implemented (2) at Twitch with BBR, filling congestion window during probe-up — increased average bitrate by 1 Mbps.

Decision: Luke to write an extension draft covering both parts. General support. Issue closed in MOQT tracker.

---

Next Interim Planning

• Next hybrid interim: There was expectation that an additional interim was needed. The week starting the 12th of October was what seen as best fitting the attending people.
• Location: Several locations (6) was volunteered in North America. The chairs will follow up with those that volunteered and confirm actual availability before doing a poll.

---

Summary of Action Items

#	Action	Owner
1	PR for location filter (separate from #1518)	Mo Zanaty
2	Work through fill fetch (PR #1642) edge cases — priorities, errors, relay chain behavior	Alan Frindell, Mo Zanaty, design team
3	Focused conversations on current group delivery with interested parties	Alan Frindell, interested participants
4	PR for request_error on stream credit exhaustion (#1637)	Alan Frindell or Ian Swett
5	Rename publish_blocked → publish_skipped + write-up	Ian Swett
6	Revisit current group delivery temperature check	Chairs (next morning)
7	Top-N filter data/discussion on Friday	Mo Zanaty
8	Concurrent subscribe: add warning text about alias risks	Editors
9	switch_from PR: proceed with hard mode, reason through soft mode edge cases	Suhas Nandakumar, Victor Vasiliev
10	DOS document: aim for -01 by Vienna	Mike English
11	#1655: More specific GOAWAY proposal	Alan Frindell
12	#1653: Come back tomorrow with clearer processing semantics	Editors
13	#1644: Try to make track properties immutable	Editors
14	#1453: Write Send Rate as extension + experimentation	Interested participants
15	#1352: Write PR to replace Forward with filter (after Object Filters land)	Suhas Nandakumar
16	#1507: Write bitrate mechanism as extension	Luke

---

Sessions Not Covered (deferred to 12 June)

• Remaining "Other MOQT Issues" slides not reached on day 1 (#1489, #1316, #1270, #1063, #974, #969, #799/#1503, #899, #881, #869, #475, #273)
• Track Filter/Top-N deep dive