QUIC Stream Resets with Partial Delivery
draft-ietf-quic-reliable-stream-reset-11

Thanks to Ionuț for the SECDIR review.

Thanks to Ionut Mihalcea for their secdir review!

Thanks for the work done in this document. While QUIC is not within my area of expertise, I have only two non-blocking COMMENT, but addressing them will probably help implementers.

### Section 4

Please add a normative reference for the syntax/notation used in Figure 1.

### Section 5.4

Why not a "MUST" in `endpoints SHOULD send a RESET_STREAM frame` ? The use of BCP14 terms is specific for interoperability, so, add guidance to implementers when the "SHOULD" can be bypassed if this is not a "MUST"

Regards,

-éric

Thanks to the authors and the WG for their work on this document.

Please take this as someone that is not an expert in this area and, therefore, 
feel free to just tell me that I am wrong and/or oversimplifying :-)

Please find below a couple of comments on this document inline in the idnits 
output of v10. Lookout for the <EoRv10> tag at the end to ensure you are seeing 
the full review.

1) Mix up of things that perhaps needs clarification

265	   Reordering of packets might lead to a RESET_STREAM_AT frame with a
266	   higher Reliable Size being received after a RESET_STREAM_AT frame
267	   with a lower Reliable Size.  The receiver MUST ignore any
268	   RESET_STREAM_AT frame that increases the Reliable Size.
270	   When sending another RESET_STREAM_AT, RESET_STREAM or STREAM frame
271	   carrying a FIN bit for the same stream, the initiator MUST NOT change
272	   the Application Error Code or the Final Size.  If the receiver
273	   detects a change in those fields, it MUST close the connection with a
274	   connection error of type STREAM_STATE_ERROR or FINAL_SIZE_ERROR,
275	   respectively.

<major> Two closely related points in this text would benefit from one 
clarification. First, “ignore any RESET_STREAM_AT frame” can be read as ignoring 
the whole frame, which would conflict with the following requirement to detect 
changes in its other fields. I think the intent is only to ignore the attempted 
increase in Reliable Size. Second, the following sentence grammatically applies 
Application Error Code consistency to a STREAM frame carrying FIN, even though 
(I believe) a STREAM frame has no Application Error Code; only Final Size 
applies to that frame type.

How about the following?

SUGGEST
Reordering of packets might lead to a RESET_STREAM_AT frame with a higher 
Reliable Size being received after a RESET_STREAM_AT frame with a lower 
Reliable Size. The receiver MUST ignore the increase in Reliable Size and 
continue to use the smallest Reliable Size received. The other fields of the 
RESET_STREAM_AT frame remain subject to the consistency requirements below.

When sending another RESET_STREAM_AT or RESET_STREAM frame for the same stream, 
the initiator MUST NOT change the Application Error Code or the Final Size. 
When sending a STREAM frame carrying the FIN bit for the same stream, the 
initiator MUST NOT change the Final Size. If the receiver detects a change in
the Application Error Code, it MUST close the connection with a connection 
error of type STREAM_STATE_ERROR. If the receiver detects a change in the 
Final Size, it MUST close the connection with a connection error of type 
FINAL_SIZE_ERROR.

2) Is that a SHOULD or indeed a MUST ?

212	   When using a RESET_STREAM_AT frame, the initiator MUST guarantee
213	   reliable delivery of stream data of at least Reliable Size bytes.  If
214	   STREAM frames containing data up to that byte offset are lost, the
215	   initiator MUST retransmit this data, as described in Section 13.3 of
216	   [RFC9000].  Data sent beyond that byte offset SHOULD NOT be
217	   retransmitted.

The above reliable-delivery requirement needs to reconcile with the the text 
below:

317	   An endpoint that receives a STOP_SENDING frame is required to send a
318	   RESET_STREAM frame in some stream states, as described in Section 3.5
319	   of [RFC9000].  While it is permissible to send a RESET_STREAM_AT
320	   frame in this case, endpoints SHOULD send a RESET_STREAM frame, since
321	   the peer has already indicated that it does not intend to process any
322	   further data.

<major> I support Éric Vyncke’s comment asking why the SHOULD in Section 5.4 is 
not a MUST. RFC 9000 Section 3.5 says that after STOP_SENDING, STREAM frames 
“can be discarded upon receipt”, while Section 5 of this draft requires a 
sender using RESET_STREAM_AT to guarantee delivery through the Reliable Size. 
A positive Reliable Size after STOP_SENDING therefore appears to create a case
where the draft requires delivery of data that RFC 9000 permits the receiver to 
discard. Please correct me if I am missing a QUIC rule that reconciles these 
requirements.

Suggestion: change the Section 5.4 SHOULD to a MUST, as Éric suggests. There may
be other ways (perhaps restricting Reliable Size to 0) to reconcile with RFC 9000?

<EoRv10>

Section 5.4:

317 >    An endpoint that receives a STOP_SENDING frame is required to send a
318 >    RESET_STREAM frame in some stream states, as described in Section 3.5
319 >    of [RFC9000].  While it is permissible to send a RESET_STREAM_AT
320 >    frame in this case, endpoints SHOULD send a RESET_STREAM frame, since
321 >    the peer has already indicated that it does not intend to process any
322 >    further data.

I support Ketan's and Éric's COMMENTs on the SHOULD here. There's a concrete
answer available that the text doesn't spell out: Section 5.2 already gives
implementers a graceful way to walk back a commitment made before
STOP_SENDING arrived.

248 >    The initiator MAY send multiple RESET_STREAM_AT frames for the same
249 >    stream in order to reduce the Reliable Size.  It MAY also send a
250 >    RESET_STREAM frame, which for purposes of data delivery is equivalent
251 >    to sending a RESET_STREAM_AT frame with a Reliable Size of zero.

If an endpoint already sent a RESET_STREAM_AT with a positive Reliable Size
before STOP_SENDING arrived, it isn't stuck honoring that commitment -- it
can follow up with a RESET_STREAM (or a RESET_STREAM_AT with Reliable Size
zero) to reduce the commitment to nothing, per Section 5.2's "MUST NOT
increase" rule, which only constrains increases. That's presumably why
SHOULD rather than MUST is sufficient here: there's always a path back to
the RESET_STREAM-equivalent behavior Ketan and Éric are asking about. Making
that connection explicit in 5.4 -- even just a cross-reference to 5.2 --
would resolve the tension both of them flagged without changing the
normative language.

---

Section 4:

158 >    RESET_STREAM_AT Frame {
159 >      Type (i) = 0x24,
160 >      Stream ID (i),
161 >      Application Protocol Error Code (i),
162 >      Final Size (i),
163 >      Reliable Size (i),
164 >    }

On the list, Martin Thomson pushed back on Éric's ask for a normative
reference here, on the grounds that the notation is illustrative and RFC
9000 is already a normative reference. That's true as far as it goes, but
RFC 9000 Section 1.3 is where this "custom format" is actually defined -- it
isn't defined anywhere else, and the draft never says so. Éric's simplest
fix from the thread (a sentence like "using the notation of Section 1.3 of
RFC 9000") costs nothing and points the reader at the right place without
adding a new reference.

----------------------------------------------------------------------
NIT
----------------------------------------------------------------------

All comments below are about very minor potential issues that you may
choose to address in some way - or ignore - as you see fit. Some were
flagged by automated tools (via
https://github.com/larseggert/ietf-reviewtool), so there will likely
be some false positives. There is no need to let me know what you did
with these suggestions.

Section 5:

208 >    A sender that wants to reset a stream but also deliver some bytes to
209 >    the receiver sends a RESET_STREAM_AT frame with the Reliable Size
210 >    field specifying the amount of data to be delivered.

212 >    When using a RESET_STREAM_AT frame, the initiator MUST guarantee
213 >    reliable delivery of stream data of at least Reliable Size bytes.

Section 5 opens by calling the party that sends RESET_STREAM_AT the
"sender," then switches to "initiator" for the normative MUST two sentences
later, and Section 5.2 uses "initiator" throughout. Section 4 and the frame
field description use "sender." Picking one term and using it consistently
would help implementors grep the document for the relevant role.

Thank you for the effort put in this well-written spec.

Thank you to Christer Holmberg for the GENART review.