Summary

  • STOP_SENDING expresses receiver disinterest in one incoming stream direction; it does not certify that prior bytes were ignored.
  • RESET_STREAM terminates only the peer's sending direction, while final size records flow-control credit consumed rather than work completed or reversed.
  • Transport observations must remain separate from application admission, cancellation acceptance, durable effects, compensation, and the final business outcome.

A client can reach a timeout, decide it no longer wants the response, and send STOP_SENDING with an application error code. That is a meaningful transport event. It tells the peer to cease transmission on one QUIC stream direction. It does not tell an operations ledger that a remote order, job, or request has been cancelled. The distinction matters because bytes and business actions do not move through the same state machine.

RFC 9000 describes STOP_SENDING as a way for an application that is no longer interested in data it is receiving to abort reading. When the receiving part is in Recv or Size Known, the transport should send STOP_SENDING to prompt closure of the opposite direction. The important qualification is explicit: the frame is not a guarantee that incoming data will be ignored. Earlier STREAM bytes may already have arrived, been delivered upward, or been acted upon. Bytes that arrive after STOP_SENDING still count against stream and connection flow control even if the transport discards them.

The peer's response is another observation, not a confirmation of a business decision. If its sending part is in Ready or Send, it must send RESET_STREAM. In Data Sent, it may defer that reset until outstanding data is acknowledged or declared lost. If data is declared lost, it should send RESET_STREAM rather than retransmit it. The peer should copy the application error code from STOP_SENDING, but it may select a different code. The sender may ignore the later RESET_STREAM error code, so the two codes belong in separate ledger fields.

Direction is the central boundary. RESET_STREAM abruptly terminates only the sending part of a stream. On a bidirectional stream, the opposite direction remains independent. A party seeking to stop both directions uses RESET_STREAM for its own sending direction and STOP_SENDING to encourage termination of the other one. Neither action closes the connection or proves that a request pair or workflow ended.

Final size is equally easy to overread. It states the amount of stream data represented for connection-level flow-control accounting. Once known, it cannot change, and it is communicated reliably whether a stream finishes normally or is reset. It does not state how much application work was completed, whether a remote operation was admitted, or whether a side effect was undone. After RESET_STREAM, the endpoint ceases transmission and retransmission of STREAM frames in that direction; that is a statement about transport behavior, not a reversal of application state.

Reliability also has a narrow meaning here. QUIC does not retransmit a lost packet as a whole. Relevant information is sent again in new frames as needed. RESET_STREAM continues until acknowledged or until all stream data is acknowledged. STOP_SENDING continues until the receiving part reaches Data Recvd or Reset Recvd. Acknowledgment or receipt therefore shows progress in the QUIC stream state machine. It cannot prove that a peer never consumed earlier bytes, accepted or declined the operation, rolled back durable effects, or completed compensation.

A sound evidence ledger records connection identity, stream ID, initiator, stream type, and the affected direction. It separately records the local decision to stop reading, each STOP_SENDING transmission and retransmission, its application error code, peer RESET_STREAM receipt and code, final size, flow-control accounting, and any later STREAM bytes. Only additional application evidence can establish remote admission or consumption, cancellation acceptance or rejection, durable effects, rollback, compensation, and the final outcome.

This boundary also prevents category errors with adjacent protocol evidence. TR-045 concerns ACK and packet processing, not this request to stop a stream direction. TR-046 concerns flow-control permission, not application cancellation. TR-052 concerns DATAGRAM message boundaries and absent delivery guarantees. TR-053 concerns CONNECTION_CLOSE and the end of transport state. STOP_SENDING is none of those: it is solicited cancellation of one stream direction on a connection that may remain active.