Re: draft-ietf-quic-reliable-stream-reset-09 ietf last call Genart review

[Christian Huitema <[e-mail]>]

On 8/3/2026 5:38 AM, Christer Holmberg via Datatracker wrote:

Not speaking for the authors. Just a quick point about flow control.
> Document: draft-ietf-quic-reliable-stream-reset
> Title: QUIC Stream Resets with Partial Delivery
> Reviewer: Christer Holmberg
> Review result: Ready with Issues
>
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
>
> For more information, please see the FAQ at
>
> <https://wiki.ietf.org/en/group/gen/GenArtFAQ>.
>
> Document: draft-ietf-quic-reliable-stream-reset-09
> Reviewer: Christer Holmberg
> Review Date: 2026-08-03
> IETF LC End Date: 2026-08-03
> IESG Telechat date: Not scheduled for a telechat
>
> Summary: The document is well written, and easy to understand. However, I do
> have some comments and questions that I'd like to authors to address.
>
> Major issues: N/A
>
> Minor issues:
>
> ---
> Section 4:
>
> The text says that RESET_STREAM_AT frames must not not violate flow control
> limits at the time of sending, and that the sender makes a commitment to
> retransmit Reliable Size amount of data.
>
> Q: What happens if the available flow control credit drops below Reliable Size
> after RESET_STREAM_AT has been sent? E.g. due to a connection migration. Should
> the draft mandate sending a new RESET_STREAM_AT frame, with a Reliable Size
> that fits the new control credit (as described in Section 5.2)?

In QUIC, flow control is a property of the connection and the stream, 
and cannot be withdrawn. It is not a property of a particular path. Flow 
control applies when adding bytes to the stream, i.e., when "reliable 
size" data are first sent. Retransmission of data tat was already send 
does not consume or require flow control credits.

-- Christian Huitema

> ---
> Section 5:
>
> The text says:
>
> "When using a RESET_STREAM_AT frame, the initiator MUST guarantee
> reliable delivery of stream data of at least Reliable Size bytes.  If
> STREAM frames containing data up to that byte offset are lost, the
> initiator MUST retransmit this data, as described in Section 13.3 of
> [RFC9000].  Data sent beyond that byte offset SHOULD NOT be
> retransmitted."
>
> Q: Are there cases where data sent beyond the byte offset would be
> retransmitted? If so, maybe adding some examples? If not, could SHOULD NOT be
> replaced with MUST NOT?
>
> ---
> Section 5.4:
>
> The text says:
>
> "While it is permissible to send a RESET_STREAM_AT frame in this case,
> endpoints SHOULD send a RESET_STREAM frame, since the peer has already
> indicated that it does not intend to process any further data."
>
> Q: Is there a reason why RESET_STREAM_AT with Reliable Size = 0 could not be
> sent? It would be explicit, and match the peer's indication that it does not
> intend to process any further data.
>
> ---
>
> Nits/editorial comments:
>
> ---
> Section 3:
>
> Q: Please add a reference to RFC 9001 for 0-RTT.
>
> ---
> Section 3:
>
> The text first says that the transport parameter is sent with an empty value,
> and then the text says that both endpoints must remember the value.
>
> Q: It sounds a little confusing to "remember an empty value". Perhaps saying
> that both endpoints must remember the presence of the transport parameter with
> the empty value, or something like that?
>
> ---
>
>
>