Ketan Talaulikar's No Objection on draft-ietf-quic-reliable-stream-reset-10: (with COMMENT)

[Ketan Talaulikar via Datatracker <[e-mail]>]

Ketan Talaulikar has entered the following ballot position for
draft-ietf-quic-reliable-stream-reset-10: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-quic-reliable-stream-reset/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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>