Return-Path: X-Original-To: gen-art@mail2.ietf.org Delivered-To: gen-art@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 584D712331A56 for ; Mon, 3 Aug 2026 23:32:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1785825159; bh=DxmHqByGRRkUFB8wxHCx5+X1EKx+IfMmAPCGGWWf6aE=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=Z+xyBs9rvHvW7j4SThJDfnbvSdALvkMKeNzM70JirPGAe+eTqr4QJrqvWTNT/Pyqj v0lghmGPP0WEI3K+j92XTnk67XA1+N2qnZcYzDtbFA40tuQGTtl9kP9Ykt0OxqJqCD scQh83jvfmqpOqWXq5W0s2xA03qtu8UCvfAq6KNw= X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uLHkSzdF7oFt for ; Mon, 3 Aug 2026 23:32:37 -0700 (PDT) Received: from mail-yx1-xb136.google.com (mail-yx1-xb136.google.com [IPv6:2607:f8b0:4864:20::b136]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 8BF6212331A2D for ; Mon, 3 Aug 2026 23:32:37 -0700 (PDT) Received: by mail-yx1-xb136.google.com with SMTP id 956f58d0204a3-6680ae2031fso3606114d50.3 for ; Mon, 03 Aug 2026 23:32:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1785825157; cv=none; d=google.com; s=arc-20260327; b=YIAYphGzvXSXYhaNnV3uq7RPmdOKJdiXcmNP/msPBvks6jnaH1S/P6zURjEFeRyRq9 QP6UWvPvqewiCKKADpOlvIRJ1j1xoKxQ+pyDXw2LXA5U1ePYyBgirUUX3m1KAVAHMebu JQqc3wx5sTRkUgQaNSVETJwv89iD1LBEtiAlcYB9jjiSD7T9m02pgZnrK+HUxGJJGhVl sBdLuGBJMsdjWMw6jt8c4+C/cLRAYhfIIY4EUhEzhA6u6lzY9sYG32pn89pGbEYIiIpq aWgSPsz34dF090IqQWcsVPVkRQPGWJeBrXYssTRUbn1E3Y6KHtw3kDUey7//w6HMxyHf 1+zg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=bvSWMmymK3wd8NqYq1P/ubx3MWMS8RGunkUmQMNKLdA=; fh=bLMZseaTADP8SWNjR+UiAdd0AlSE/dq5+6z2ppI4U3Q=; b=rrJPQP6QVFsDiO7WCtKwyZL+qILfbMjGTnkZybZ3GKDvN7Su3OtG0nIbVi4HziKhTo XDfXQbYWV0qs0EMhTe7Y+Kgc/ERLXyPCiA1aMzBUqSoFarzTYH0nSv/LObtWy96lK8sA SYI52EyM/Jx7NiUK/VKgzrNV69XYf1wSD2BJK/TXZYEuPciIVxRpcWGNEbp8/vG8cPg7 hvvjRG/seUAHf/KP1m/0erhuEKf+xstTkETw2d5BW2BtIe2xp8DMCJW45W2W9PdhZIXm Qs/gpjoVj/99adpqRYsm0398QXDY9H9C584+AhnFpyRiouQSUXT9+8cSERr5KBl6fgUc fEiw==; darn=ietf.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1785825157; x=1786429957; darn=ietf.org; h=content-type:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to :content-type; bh=bvSWMmymK3wd8NqYq1P/ubx3MWMS8RGunkUmQMNKLdA=; b=NPl9Nm5rB6LvxpZjKL5qStuMAUzcNTqGqWR/r8nuXvIQLF6lphJY+eYCVoxutwKrsy TT2S++vvbTNT80ZNRx9rbZV92uTt4uXeWy4n0n5bFtx6xwj1AO9vMvwxn7lV4CRGyAdl IgisN1Mga4G0VMWCDBtBMX4m7oQLfwG25F0nrob8ycDQ3A9cF8YZy4BanCb/ArhEIbmK KnSs9M7RbnKT3jNVSB8pKIvhRZXfNAoE+gdByTcs9SksTOwZ7kaX61OlFRnqgveTTrov 8f57JbCmhTQGMztfSl+XJuWkjX5fI+NJ7jl9iarizMZRgT3C7kgcxloHeYDpVDH0qNP2 1XfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785825157; x=1786429957; h=content-type:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=bvSWMmymK3wd8NqYq1P/ubx3MWMS8RGunkUmQMNKLdA=; b=rh0HokubIGkYGN/gbdpmDbE6S8nHUEZJ/oTs8BT1Arw0PHQbg1j2E5LgmdLtOGrhV4 X3ak6KRNM/YRy0tFT76dNeu++vH6QjVTk9zCLpAoUijwY1CM4qEXOihwMJBC/P0BjfwA elUsMK5UivIvtdoySGDAL1u4xvcXRVdRIwvOkzQyhPAeTsMhTlIfOPn5VfbT0SO1z6NT MQ3Zd6AF/9A5QrVNq0cwh/8+HGdC+OMWKyFmHr6IErhkHoFnNYkzF8bzMvJJ6GoM3uPR GbkWMndiUWnUw7m4rmgoQCBJskAaMDr9MmBm9AG6uoGc9NtbEn8E+4VvEbS0tLe/jV98 izug== X-Forwarded-Encrypted: i=1; AHgh+RomPn8SnPs+3Eo9DbycL0Ql7Ej4gpDu2dV7lsxTSolYS3NVDAbuIN+vwOp21lNmFoPFVkokmgZ9@ietf.org X-Gm-Message-State: AOJu0Yxx+jRO0RiRRkFIdJTwYPtOEX747EuR+G0fa8xvDvOqWc9MbxOT 0x/72yfvZUqiJvXnsaLdJHpjiSsNMJyKBlUdto6RpCyfMG2rtQdjIlSwA8FV5GZ7Y/CxxUHfq9W lhdxW9SOkvy5gW+xuCaWwtIkxrs98vvI= X-Gm-Gg: AR+sD12rDdNQjcUDDd32chXugNE2AbcABXxvt/4dE3OufSZTFOVo8UskEIPNJIFOt4D OJjnuccsVfGk3JCxtANnfrqJHaxMNGCPPZpnnoG3ifQNlpf7DzEO4BFPN9todkw7FiQTMpRJaZc NtKnjll48f91STCmEJGIGT+KzrfGSTLZ4HgkLGKrKFnUMQkEZoj4CP7abcgOlWbdjyOMM7Z+Gga BDgqznH/Pnp03E1GSTDFGw+9xvSAq0nEgUnizVuoA0pnbTWvMlL84vA92f8A6NVMdG3KwrXG+ne q9YI1WtqAUkCrx+tUHBq5eHOWatUuYGS7X6GiG+ZHcMh X-Received: by 2002:a05:690e:4385:b0:668:bf66:4e69 with SMTP id 956f58d0204a3-6694f1bacd9mr11277616d50.36.1785825156984; Mon, 03 Aug 2026 23:32:36 -0700 (PDT) MIME-Version: 1.0 References: <178576073151.1915479.14385230021826342697@dt-datatracker-d4d6ff9d9-fsx7d> <52159ff3-901d-40d0-8949-dd1aea1161ed@huitema.net> In-Reply-To: <52159ff3-901d-40d0-8949-dd1aea1161ed@huitema.net> From: Marten Seemann Date: Tue, 4 Aug 2026 14:32:25 +0800 X-Gm-Features: AUfX_mzGvhzWYQgpvgLGxHsrwGFSOS_YJ0ohDY1vHCldrOmj13ORYfitOC4-KTM Message-ID: To: Christian Huitema Content-Type: multipart/alternative; boundary="0000000000001cf502065832d2d2" Message-ID-Hash: BOQFGZ7ZV3VS77TSAEOFKUNWV6WII5CS X-Message-ID-Hash: BOQFGZ7ZV3VS77TSAEOFKUNWV6WII5CS X-MailFrom: martenseemann@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-gen-art.ietf.org-0; header-match-gen-art.ietf.org-1; header-match-gen-art.ietf.org-2; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: gen-art@ietf.org, draft-ietf-quic-reliable-stream-reset.all@ietf.org, last-call@ietf.org, quic@ietf.org X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BGen-art=5D_Re=3A_draft-ietf-quic-reliable-stream-reset-09_ietf_?= =?utf-8?q?last_call_Genart_review?= List-Id: "GEN-ART: General Area Review Team" Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --0000000000001cf502065832d2d2 Content-Type: text/plain; charset="UTF-8" > 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 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 > > > > . > > > > 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? > > > > --- > > > > > > > --0000000000001cf502065832d2d2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>=C2=A0Q: What happens if the available flow control cr= edit drops below Reliable Size
after RESET_STREAM_AT has been sent? E.g. due to a connection migration. Sh= ould
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)?
<= br>
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.=C2=A0 If<= br> 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].=C2=A0 Data sent beyond that byte offset SHOULD NOT be
retransmitted."

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

>=C2=A0Q: Is there a re= ason why RESET_STREAM_AT with Reliable Size =3D 0 could not be
sent? It would be explicit, and match the peer's indication that it doe= s not
intend to process any further data.

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

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

T= he 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 referenc= ing RFC 9001 provides much value, especially since we're not changing t= he QUIC derivation paths.

>=C2=A0Q: It sounds a= little confusing to "remember an empty value". Perhaps saying that both endpoints must remember the presence of the transport parameter w= ith
the empty value, or something like that?


On= Tue, 4 Aug 2026 at 01:30, Christian Huitema <huitema@huitema.net> 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.=C2=A0 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 addre= ss.
>
> Major issues: N/A
>
> Minor issues:
>
> ---
> Section 4:
>
> The text says that RESET_STREAM_AT frames must not not violate flow co= ntrol
> 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 Relia= ble Size
> after RESET_STREAM_AT has been sent? E.g. due to a connection migratio= n. 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.=C2= =A0 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].=C2=A0 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 =3D 0 coul= d not be
> sent? It would be explicit, and match the peer's indication that i= t 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 parame= ter with
> the empty value, or something like that?
>
> ---
>
>
>
--0000000000001cf502065832d2d2--