]> Mozilla

mt@lowentropy.net

Transport QUIC next generation unicorn sparkling distributed ledger Sending on QUIC streams can only be aborted early by the sender with a RESET_STREAM frame. This document describes how a receiver can indicate when the data they have received is enough, allowing the sender to reliably deliver some data, but abort sending for anything more than the indicated amount. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the QUIC Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction RFC 9000 describes how streams can be completed or reset. A completed stream is delivered in its entirety, with the sender sending new STREAM frames until all data has been received and acknowledged by a receiver. On the other hand, data on a reset stream might never be sent, or - if it is sent - it might not be retransmitted in the case of loss. The RESET_AT frame provides a way for a sender to split a stream into two parts: an early part that is transmitted reliably and any remainder, which is effectively reset. This combines aspects of both completed and reset streams, even though the entire content of a stream is not delivered. This document describes the ENOUGH frame in , which provides an analogue of the STOP_SENDING QUIC frame (). This allows a stream receiver to indicate that it has received enough data and that any data beyond the indicated offset is not needed. A sender that receives this ENOUGH frame can cease sending and emit a RESET_AT frame at or beyond the indicated offset.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

QUIC ENOUGH Frame A QUIC ENOUGH frame (0xTBD) is shown in .

The QUIC ENOUGH Frame Format

Like STOP_SENDING, an ENOUGH frame can be sent for streams in the "Recv" or "Size Known" states; see . Receiving a STOP_SENDING frame for a locally initiated stream that has not yet been created MUST be treated as a connection error of type STREAM_STATE_ERROR; see . An endpoint that receives an ENOUGH frame for a receive-only stream MUST terminate the connection with error STREAM_STATE_ERROR. ENOUGH frames contain the following fields:

Stream ID:

A variable-length integer carrying the stream ID of the stream being ignored.

Application Protocol Error Code:

A variable-length integer containing the application-specified reason the sender is ignoring the stream; see .

Offset:

A variable-length offset into the stream. Note that a value of 0 makes this frame equivalent to STOP_SENDING. This value MAY be larger than the final size of the frame; see , in which case this frame has no effect.

ENOUGH frames have no direct effect on the stream state machine.

Negotiation Endpoints advertise their support of the extension described in this document by sending the enough (0xTBD) transport parameter () with an empty value. An implementation that understands this transport parameter MUST treat the receipt of a non-empty value as a connection error of type TRANSPORT_PARAMETER_ERROR; see . In order to allow reliable stream resets in 0-RTT packets, the client MUST remember the value of this transport parameter. If 0-RTT data is accepted by the server, the server MUST not disable this extension on the resumed connection. This extension MUST NOT be advertised unless support for the RESET_AT frame is also advertised; see . An endpoint MUST treat receipt of this transport parameter without the reliable_reset_stream transport parameter as a connection error of type TRANSPORT_PARAMETER_ERROR.

Security Considerations TODO Security

IANA Considerations This document has no IANA actions.

Normative References Protocol Labs 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. This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.

Acknowledgments Martin Duke asked if this was possible. This is the result.