Summary

  • QUIC draft revision 11 now expressly forbids RESET_STREAM_AT unless the peer advertised the empty reset_stream_at transport parameter. That is permission to use a frame, not proof of application agreement about what must survive a reset.
  • Reliable Size is a minimum, not an exact cutoff or an immutable promise. Later reset information may only reduce it, and reordered older frames cannot restore a larger value.
  • WebTransport separately requires its session header inside the reliable prefix. That application rule, not transport negotiation alone, prevents an aborted stream from arriving without the identity needed to account for it.

Revision 11 is an approval-stage draft, not an RFC

The event is unusually narrow and therefore useful. On 6 September 2026, Marten Seemann and Kazuho Oku submitted revision 11 of QUIC Stream Resets with Partial Delivery. The IETF Datatracker identifies it as an active QUIC Working Group standards-track Internet-Draft. Its recorded states include Submitted to IESG for Publication, IANA OK — Actions Needed, and Approved-announcement to be sent. The IESG has approved the document, but the official approval announcement and RFC publication are not the same event. This article calls it a draft and makes no RFC-number claim.

Revision 11 followed the 3 September IESG telechat and incorporated review comments rather than merely renewing an expiry date. Compared with revision 10, it adds an explicit negotiation prohibition, defines Reliable Size as a minimum, clarifies that current reset information—not a packet-shaped copy of an old frame—is retransmitted, separates field-consistency checks, explains how a reordered larger value is handled and changes the response guidance for STOP_SENDING.

Those edits expose the protocol's institutional structure. A short transport parameter grants a capability. A reset frame declares an error, a final accounting size and a surviving delivery floor. The application protocol decides whether some header is indispensable. The receiving application can later withdraw interest. Calling all four steps “reliable reset” obscures who may decide what.

The peer first grants permission to use the frame

Support is advertised through reset_stream_at, encoded as transport parameter 0x1d with an empty value. A receiver that understands the parameter must treat a non-empty value as TRANSPORT_PARAMETER_ERROR. Revision 11 then adds the sentence that had previously been assumed: an endpoint MUST NOT send RESET_STREAM_AT unless its peer advertised this support.

That is more than editorial tidiness. Extension code can exist at one endpoint without being active for a particular connection. The wire cannot infer consent from software version, vendor family, a previous session or a belief that unknown frames will be tolerated. The peer's handshake state is the authority. Without it, frame type 0x24 is not available to the sender.

Resumption makes the boundary temporal. For 0-RTT, both endpoints remember whether the server advertised the extension. If the server accepts early data, it must not disable the extension on the resumed connection. Otherwise, the client could emit a frame under remembered authority and meet a server that silently withdrew that authority after accepting the early-data context. A server remains free to reject 0-RTT; acceptance while changing the advertised capability is the forbidden combination.

The rule still proves only parse permission. It does not prove that the application has assigned meaning to any particular prefix, that a relay can account for the stream, or that a positive Reliable Size will remain positive.

Reliable Size is a floor that can move downward

RESET_STREAM_AT contains Stream ID, Application Protocol Error Code, Final Size and Reliable Size. Final Size preserves QUIC's accounting view of how many bytes the sender produced. Reliable Size states the minimum prefix that must reach the receiving application despite the reset. If Reliable Size exceeds Final Size, the receiver closes the connection with FRAME_ENCODING_ERROR.

The distinction between “minimum” and “amount” matters. Below the Reliable Size, lost STREAM data must be retransmitted. Above it, the sender should not retransmit, yet a receiving stack may still deliver bytes it already has. Reliable Size is therefore not a byte-excision boundary. A product that discards already-arrived bytes merely to make observed delivery equal the field would be inventing semantics the draft does not require.

The first floor is not permanent either. A sender may issue later RESET_STREAM_AT frames with a smaller Reliable Size, or send ordinary RESET_STREAM, which is delivery-equivalent to reducing the floor to zero. It may never increase the value. The current Reliable Size information and all data below it remain subject to retransmission until acknowledged.

This creates a one-way option. The sender can surrender delivery responsibility that it had previously announced, but cannot reinstate a larger guarantee after shrinking it. The receiver's operational truth is the smallest valid value it has seen, not the largest promise that once crossed the network.

Reordering does not restore an older promise

Packet order is not decision order. Suppose the sender first declares 120 bytes reliable and later lowers the floor to 24. The packet carrying 24 can arrive first. When the older packet carrying 120 appears later, revision 11 instructs the receiver to ignore the attempted increase and continue using 24.

Revision 10 said to ignore a RESET_STREAM_AT frame that increased Reliable Size. Reviewers observed that “ignore the frame” could also suppress checks of its Application Error Code or Final Size. Revision 11 narrows the instruction: ignore the increase, not the rest of the evidence. Error Code must remain consistent across reset frames. Final Size must remain consistent across reset frames and a STREAM frame carrying FIN. A changed Error Code produces STREAM_STATE_ERROR; a changed Final Size produces FINAL_SIZE_ERROR.

This is a small example of reality-layer discipline. Reliable Size, error reason and final accounting size share one frame but carry different claims. Reordering can make one claim stale without making the others irrelevant. A parser that maps the whole frame to a single “old/new” bit loses the very inconsistency evidence needed to protect stream state.

Application protocols must name the irreducible prefix

The transport draft explicitly allows an application protocol to set a threshold below which Reliable Size must not be reduced. This is where partial reliability gains meaning. Transport knows byte offsets. It does not know that the first bytes identify a session, subscription or object family.

WebTransport over HTTP/3 supplies a concrete contract. Its current revision requires implementations that reset a WebTransport data stream to use RESET_STREAM_AT with a Reliable Size at least as long as the WebTransport header. The purpose is to deliver the ID that associates the stream with a WebTransport session. Without that identifier, the receiver may observe an aborted stream without knowing which session owns the error or accounting consequence.

The reviewed Media over QUIC transport draft uses a related but not identical rule. When RESET_STREAM_AT is used for a subgroup stream, Reliable Size should include the stream header so the subscriber can identify the subscription and account for reset data streams when processing PUBLISH_DONE. It warns that an inadequate floor can leave subscription state alive until timeout.

The difference between MUST and SHOULD is material. It reflects application governance, not a contradiction in QUIC. A reusable transport extension can offer a decreasing floor. Each protocol using it must decide whether loss of its prefix is tolerable, when departure is allowed and what state leaks if the prefix disappears. Negotiating reset_stream_at cannot answer those questions on behalf of WebTransport or MoQ.

STOP_SENDING turns reliability into a retreat decision

QUIC's STOP_SENDING means the receiving application no longer wishes to receive stream data. Revision 11 says that if an endpoint answers with RESET_STREAM_AT, it should set Reliable Size to zero, because the peer has already indicated that it will not process more data.

That guidance resolves a tension. Continuing to retransmit a positive prefix after the receiver withdrew interest spends congestion, flow-control and state resources to enforce a promise whose beneficiary has departed. Reducing the floor to zero gives the sender a specified path back to ordinary-reset behavior. It also proves why the initial Reliable Size must not be described as irrevocable.

Application rules can still be stricter in a specific context. An intermediary may need enough header to route an error or settle accounting across another hop. If so, that protocol must explain why a zero retreat is not permitted and how it reconciles the decision with the peer's cancellation. Reliability is not moral superiority over cancellation. It is a scoped obligation whose owner and exit conditions must be explicit.

Flow control and resource commitments survive the reset label

Final Size remains subject to both stream- and connection-level flow control. A sender may need to postpone RESET_STREAM_AT until the receiver has granted sufficient credit. A reset that exceeds those limits is a FLOW_CONTROL_ERROR. The frame is ack-eliciting and its information is retransmitted when lost. Required prefix bytes may take several round trips to complete.

For that reason, “reset” does not mean “free everything now”. On the sending side, stream state cannot reach Data Recvd until the current smallest Reliable Size and the data below it have been acknowledged. On the receiving side, Data Recvd waits until those bytes arrive. The security section requires continued attention to resource commitment and exhaustion until that work ends.

This is the cost ledger behind the feature. The sender chooses a floor, but the peer supplies buffers, flow-control credit, receive processing and time. An application protocol that casually chooses a large irreducible prefix externalizes its reliability preference. Monitoring should therefore record negotiated support, initial and smallest Reliable Size, bytes retransmitted below the floor, Final Size, cancellation timing, completion latency and state retained after reset. A green “reset sent” counter is not enough.

Scope limits

The source packet establishes specifications, revision history and review reasoning. It does not establish deployment share, performance benefit, implementation correctness or a production incident. No browser, CDN, QUIC library, relay or media service was tested. The IANA review state records that actions are needed; this analysis does not claim every requested registry entry is already final.

WebTransport revision 16 and MoQ transport revision 17 are also works in progress. Their MUST and SHOULD language is evidence of how applications can use the transport hook, not a forecast that those exact sentences will survive publication. Revision 11 itself can still change during the publication process.

The durable conclusion is narrower. Permission to parse an extension, a sender's current minimum delivery commitment, an application's indispensable header and a receiver's request to stop are separate authorities. Running code stays intelligible only when implementations preserve those distinctions in state, tests and telemetry.

Sources