[quicwg/base-drafts] Inconsistency in STOP_SENDING requirements relative to resetting streams in general (#2884)

[mjoras <[e-mail]>]

Section 11.2 of the transport draft reads:

>RESET_STREAM MUST be instigated by the protocol using QUIC, either directly or through the receipt of a STOP_SENDING frame from a peer. RESET_STREAM carries an application error code. Resetting a stream without knowledge of the application protocol could cause the protocol to enter an unrecoverable state. Application protocols might require certain streams to be reliably delivered in order to guarantee consistent state between endpoints.

This would suggest that the transport implementation itself should not be deciding to send RESET_STREAMs on its own, rather it is a matter of the application protocol using QUIC. However, it is somewhat weaselly about STOP_SENDING. My original interpretation of this text was that the implementation should expose the fact that a STOP_SENDING has been received, but it is up to the application protocol to actually reset the stream. This interpretation is not consistent with section 3.5, Solicited State Transitions: 

> A STOP_SENDING frame requests that the receiving endpoint send a RESET_STREAM frame. An endpoint that receives a STOP_SENDING frame MUST send a RESET_STREAM frame if the stream is in the Ready or Send state. If the stream is in the Data Sent state and any outstanding data is declared lost, an endpoint SHOULD send a RESET_STREAM frame in lieu of a retransmission.
I believe the only reasonable way to interpret this is that the transport itself should respond to the STOP_SENDING by issuing a RESET_STREAM.

Requiring that the QUIC implementation itself reset the stream seems to go against the philosophy that the protocol should have complete control over resets. It's true that in the case of receiving a STOP_SENDING, the protocol on the other side is asking for a RESET_STREAM, but the entity being solicited should be its peer protocol implementation, not the QUIC implementation. I believe we can fix this by altering the normative text requiring sending a RESET_STREAM, instead prescribing that an application protocol ought to handle STOP_SENDING by eventually fulfilling the solicited reset.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2884