[kixelated]

Problem

Reading QUIC bytes currently returns receive credit before a header or frame is complete. Concurrent partial messages can therefore retain much more memory than the connection window. The speculative frame allocation budget and soft media cache do not provide this bound.

Approach

Add two ordered m1 quests under the existing QUIC line: native connection-credit ownership, then complete-message assembly with receiver priority cancellation. Retain stream-window configuration with a very large default, replenish stream credit on reads, and hold connection credit until complete-unit handoff. Require the memory allowance to fit the largest supported encoded unit. Align bitrate pacing and runtime peer limits, and keep #5208 held behind the shared receive-memory solution.

Impact

• Planning only: no runtime API, wire format, or shipped defaults change in this PR.
• Planned native API: receive-credit ownership and pressure observation through moq-quic and both native adapters. Browser/iroh receive capabilities are not promised.
• Planned behavior: existing stream-window overrides remain honored; memory configuration fits supported encoded messages; MoQ selects STOP_SENDING victims, including highest-priority control streams as a last resort. No new MoQ wire messages.

Alternatives

A header-specific quota, speculative allocation fallback, sender-side shedding, and withholding both credit types until message completion do not match the settled scope. Completed-cache memory remains separate. Rate pacing uses a separate allowance inside the memory cap.

Follow-ups

The two implementation quests are the follow-up work. Existing docs are updated inline during implementation. #5208 remains held; a release backport needs compatibility assessment because this work targets moq-quic after the fork switch.

Validation

quest check (455 documents), git diff --check, and nix develop --command just check passed.

Decision record

All receive-memory interview prompts and the maintainer's final selections are recorded below. Earlier selections that were subsequently corrected are identified explicitly.

Prompt	Selected answer	Other option / clarification
Header budget: configurable 64 MiB request-header cap with TooManyRequests, or shared frame-style allocation?	✅ Shared allocation prompted investigation of flow control for all incomplete units.	The explicit header cap/error was not approved; speculative allocation fallback alone does not bound received bytes.
Goal/scope: native end-to-end receive-credit ownership or transport primitive only?	✅ Native end-to-end: moq-quic, tokio/uring, and MoQ header/frame receivers after the fork switch.	Completed media caching stays separate. The implementation is split into two dependent quests.
Stream window: maximum encoded unit or small prefix then expand?	✅ A very large default stream window so it ordinarily does not constrain progress.	The maintainer initially suggested no stream window, then explicitly retained configuration and overrides.
Recovery: receiver cancellation or sender-only shedding?	✅ Receiver STOP_SENDING only.	Initially both were considered because senders know more priority; the maintainer explicitly corrected this to receiver-only. Sender RESET_STREAM in response remains required QUIC behavior.
Documentation: carry existing docs inline or create a guide quest?	✅ Existing docs inline.	No separate guide quest.
Victim ownership: MoQ chooses or QUIC automatically cancels its lowest-priority stream?	✅ MoQ chooses; QUIC exposes pressure and performs cancellation.	Reuse subscription priority, group order, and broadcast fairness domains.
Existing stream-window setting: reject it on moq-quic or keep the override?	✅ Keep and honor it, with a very large default.	Do not remove or ignore it without benchmarks demonstrating value and a new maintainer decision.
Rate-cap compatibility: separate memory allowance from pacing or refuse units larger than the rate window?	✅ Separate memory allowance from rate pacing; memory allowance is the cap.	A large frame can arrive over multiple rate intervals without enlarging the rate burst.
Credit release: stream on read plus connection on complete handoff, or hold both until completion?	✅ Stream credit on read; connection credit on complete handoff.	Stream credit should be large enough that its replenishment ordinarily does not matter.
Unit larger than memory cap: refuse the unit early or require configuration to fit every supported unit?	✅ Require configuration to fit every supported encoded unit, including framing.	The maintainer rejected a cap below one legal frame; lowering frame limits would be a separate decision if memory cost warrants it.
Unidentified partial header: cancel it before attributed media or give it a chance to identify itself?	✅ Cancel low-priority attributed media first.	Unidentified streams remain eligible if needed for progress.
Essential control: protect from ordinary eviction or make eligible even if cancellation ends the session?	✅ Eligible, but highest priority.	No permanently immune class or separate control reserve. Protocol-required session failure must be surfaced.
Publish and land the plan?	✅ Create a PR and run quest-merge.	Review and passing checks remain required.

(Written by GPT-6)

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-10-11T03:26:35.435999Z	4167479	Draft marked ready

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

• Configuration used: Organization UI
• Review profile: CHILL
• Plan: Advanced
• Run ID: 00a2a271-0cba-46ba-b960-55f6e686bb9c

---

📥 Commits

Reviewing files that changed from the base of the PR and between 5978e61 and 4167479.

---

📒 Files selected for processing (6)

• quest/m1/ietf-dispatch-headers.md
• quest/m1/quic/README.md
• quest/m1/quic/peer-limits.md
• quest/m1/quic/receive-credit.md
• quest/m1/quic/receive-memory.md
• quest/m2/rate-quic.md

---

Included review availability: This review used your included allowance. Your plan provides up to 4 included reviews per hour; 0 remain after this review.

---

---

Walkthrough

The PR updates QUIC planning documents and adds quests for receive-credit ownership and bounded incomplete-message assembly. The plans describe when connection credit is retained and released, how receiver cancellation addresses assembly pressure, and how runtime limits preserve memory accounting. They also distinguish ingress rate pacing from the memory allowance and add tests for the specified limits and recovery behavior.

Priority: ⬇️ Low

Merge Risk: ⚪ Minimal · up to 41674

This PR updates plans rather than shipped behavior, and the supplied changes establish no actionable merge-blocking risk. Merge readiness is minimal risk.

Pre-merge checks | 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check		The title clearly and concisely describes the main change: planning flow-controlled receive memory for the QUIC stack.
Description check		The description directly explains the receive-memory problem, planned quests, scope, behavior, alternatives, follow-ups, and validation for the documented changes.
Docstring Coverage		No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 0…
Linked Issues check		Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check		Check skipped because no linked issues were found for this pull request.

---

✨ Finishing Touches

✨ Simplify code

• Commit to this branch
• Create a new PR

---

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

---

_{Comment @coderabbitai help to get the list of available commands.}