Re: I-D Action: draft-ietf-quic-reliable-stream-reset-00.txt

[Christian Huitema <[e-mail]>]

On 4/23/2023 1:07 PM, [e-mail] wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This Internet-Draft is a work item of the QUIC (QUIC) WG of the
> IETF.
> 
>     Title           : Reliable QUIC Stream Resets
>     Authors         : Marten Seemann
>                       奥一穂
>     Filename        : draft-ietf-quic-reliable-stream-reset-00.txt
>     Pages           : 6
>     Date            : 2023-04-23
> 
> Abstract:
>     QUIC ([RFC9000]) defines a RESET_STREAM frame to reset a stream.
>     When a sender resets a stream, it stops retransmitting STREAM frames
>     for this stream.  On the receiver side, there is no guarantee that
>     any of the data sent on that stream is delivered to the application.
>     This document defines a new QUIC frame, the RELIABLE_RESET_STREAM
>     frame, that resets a stream, while guaranteeing reliable delivery of
>     stream data up to a certain byte offset.

A comment on the abstract itself: I am a bit put off by the use of 
"guaranteed". The frame is "requesting" delivery up to the specified 
limit. Whether this happens depends on multiple factors -- the local 
QUIC stack or the remote peer can decide to close the connection, for 
example if there are too many transmission errors.

> 
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-quic-reliable-stream-reset/
>

Otherwise, I find the text easy to read, except for a few small nits.

In section 4, the text says:

    RELIABLE_RESET_STREAM frames are ack-eliciting.  When lost, they MUST
    be retransmitted, unless a RESET_STREAM frame or another
    RELIABLE_RESET_STREAM frame was sent for the same stream (see
    Section 5.1).

There is another case for not retransmitting the RELIABLE_RESET_STREAM 
frame: if the entire content of the stream has been acknowledged by the 
peer. This is the classic race condition between FIN and RESET, and that 
race condition can of course happen with FIN and the 
RELIABLE_RESET_STREAM. It might be useful to document that race 
condition, so application designers do not rely on the "guaranteed" 
delivery of the RELIABLE_RESET_STREAM and the Application Protocol Error 
Code that it conveys.

In section 5, the text says:

    As described in (Section 3.2 of [RFC9000]), it MAY deliver data
    beyond that offset to the application.

Editorial, but who is "it" there? The only actor mentioned in the 
section is "the initiator", and that's probably not what you mean.

-- Christian Huitema