Does this frame class as an abrupt or clean close?

[LPardue]

QUIC section 2.4 describes operations on streams that includes:

• write data, understanding when stream flow control credit (Section 4.1) has successfully been reserved to send the written data;

• end the stream (clean termination), resulting in a STREAM frame (Section 19.8) with the FIN bit set; and

• reset the stream (abrupt termination), resulting in a RESET_STREAM frame (Section 19.4) if the stream was not already in a terminal state.

I'm going to say that implicitly this spec counts as an abrupt termination, if so it might help to state that explicitly and point to the RFC section. The reason I care is because HTTP/3 has different rules about handling stream data (frames) depending on whether things are clean or abrupt; see https://www.rfc-editor.org/rfc/rfc9114.html#section-7.1-6

[marten-seemann]

I have to admit I'm a bit confused by the terminology here. As far as I can tell, RFC 9000 doesn't define what "abrupt termination" means.

On the sender side, both FIN and RESET_STREAM are abrupt: No data is sent after either of them. On the receiver side, the abruptness depends on the API exposed by the QUIC stack. In an order-byte-stream API, the FIN is only delivered to the application once all data is read (-> not abrupt), whereas a RESET_STREAM can be exposed immediately (-> abrupt), but it's totally valid to first deliver received stream data first.

With that argument, RESET_STREAM_AT would be a non-abrupt termination, since the receiver will potentially have to wait for transmission of STREAM data up to the Reliable Offset.

[kazuho]

“Abrupt termination” is a concept of HTTP/3 that maps to resets in QUIC; see RFC 9114 section 4.1.1.

I’m not sure if QUICWG is at a position to specify what a QUIC extensions means to HTTP/3, but considering that RESET_STREAM_AT is a form of reset, it would be natural to consider the use of the frame as a form of an abrupt termination (and that matches the intended use case of reliably forwarding a partial response).

[LPardue]

I have to admit I'm a bit confused by the terminology here. As far as I can tell, RFC 9000 doesn't define what "abrupt termination" means.

It does in section 2.4 of RFC 9000 that I quoted

[LPardue]

I'm not sure if QUICWG is at a position to specify what a QUIC extensions means to HTTP/3, but considering that RESET_STREAM_AT is a form of reset

I agree with both these statements. My thinking is that if any new text is needed at the H3 later, we make WebTransport over H3 responsible for doing it, even if thet requires a formal Updates on RFC 9114.

We can probably avoid thst though if we can frame the terms in a way that already align, as suggested. The point of this issue is to make sure we've considered that.

[kazuho]

How about changing the last sentence of the Introduction from: This frame allows an endpoint to mark a portion at the beginning of the stream which will then be reliably delivered, even if the stream was reset. to something like: This frame allows endpoints to communicate a variant of reset that reliably delivers the beginning stream up to a specified offset.

In this way, we can convey that Reliable Resets are a form of a stream reset (a.k.a. abrupt termination) as defined in RFC 9000 section 2.4.

[LPardue]

I might go further and switch the paragraph around to match how things are presented in rfc 9000. Something like

This document extends QUIC with a variant of stream resets that reliably delivers the beginning of a stream up to a sender-specified offset, communicated using the RESET_STREAM_AT frame. As a variant of reset, application protocols continue to treat this stream function as an abrupt termination; see Section 2.4 of RFC 9000.

If you don't like my suggestion, that's OK. This is editors discretion.