[Gen-art] Re: draft-ietf-quic-reliable-stream-reset-09 ietf last call Genart review

[Marten Seemann <[e-mail]>]

> 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)?

What Christian said.

> "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."

This is unchanged from RFC 9000: Retransmitting data after RESET_STREAM is
not forbidden, it's just pointless and wasteful.

> 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.

RESET_STREAM_AT with Reliable Size = 0 is equivalent to RESET_STREAM, as
explained in section 5. Nothing stops you from sending a RESET_STREAM_AT,
you're just using more bytes on the wire to encode the same thing.

>  Q: Please add a reference to RFC 9001 for 0-RTT.

The requirement to remember transport parameters comes from section 7.4.1
of RFC 9000. RFC 9000 mentions 0-RTT 85 (!) times. I don't think
referencing RFC 9001 provides much value, especially since we're not
changing the QUIC derivation paths.

> 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?

https://github.com/quicwg/reliable-stream-reset/pull/91

On Tue, 4 Aug 2026 at 01:30, Christian Huitema <[e-mail]> wrote:

>
> 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?
> >
> > ---
> >
> >
> >
>