Behavior on STOP_SENDING

[martinduke]

We should probably have some normative text on the reaction to STOP_SENDING. In general, RFC9000 senders should respond to STOP_SENDING with an immediate RESET_STREAM.

If the receiver has indicated it doesn't want the bytes the sender thinks are reliable, what then?

I'm leaning towards sending RESET_STREAM_AT with any desired reliable_size, regardless of receiver intent, but I don't feel strongly about it.

[marten-seemann]

It seems wasteful to guarantee reliable delivery of any part of the stream if the receiver has already indicated that it won't read any of that data.

Therefore, I'd prefer to keep the RFC 9000 logic unchanged: STOP_SENDING triggers a RESET_STREAM, not a RESET_STREAM_AT.

@martinthomson once suggested introducing an ENOUGH frame (https://datatracker.ietf.org/doc/draft-thomson-quic-enough/) to request a stream offset at a particular offset, but we never came up with a problem for this proposed solution (especially since it's unclear how the receiver would know the offset before having received the data).

[marten-seemann]

Since we're not changing the logic defined in RFC 9000, I don't think we need to make any changes to this document.

@martinduke Do you think it would be beneficial to explicitly call out that the STOP_SENDING behavior remains unchanged? If so, would you mind making a text suggestion?

[LPardue]

@martinduke pinging you again

[martinduke]

If the judgment is to leave it unchanged, I don't think additional text is a big deal. But if it were me, I'd add a paragraph at the end of Section 5, saying:

"A RESET_STREAM_AT frame is not an appropriate response to a STOP_SENDING frame."

[martinthomson]

But it is, isn't it?

If you implement a checkpoint API for "reliable" stream content, then STOP_SENDING would result in RESET_STREAM_AT. That is, the endpoint that is sending can decide to commit to sending some amount of content and the receiver, despite their attempts to ignore the stream, isn't given a choice about the data being delivered.

There are few cases where that's necessary, but I'd remind everyone what more STREAM frames are also a valid response to STOP_SENDING.

[LPardue]

Seems like you might be in the rough here Martin Duke. Can we close?

[martinduke]

Seems like you might be in the rough here Martin Duke. Can we close?

Huh?

Duke: We should write something down. I guess RESET_STREAM_AT?

Seemann: No, send RESET_STREAM

Duke: Sure, let's write it down.

Thomson: No, send RESET_STREAM_AT (+1 Kazuho)

How am I in the rough?

[kazuho]

I think the question is about the semantics that we want to have for STOP_SENDING.

Does STOP_SENDING indicate:
a) that the receiver has read all data on that stream that the receiver needed, or
b) that the receiver is hoping for the sender to stop once the sender sends necessary data as required by the application protocol?

IIUC, WebTransport over HTTP/3 assumes b. Even for a stream on which a STOP_SENDING frame has been received, the sender has to send the first quic int.

Based on this understanding, I think the correct response to this issue is to state explicitly that the sender MUST NOT reduce Reliable Size and deliver data up to that size.

PS. And the another aspect of WebTransport over HTTP/3 requiring such a behavior is that the endpoints of WebTransport over HTTP/3 have to always provide flow control credits for sending at least the first quic int, so that the sender can send the quic int after receving STOP_SENDING.

[LPardue]

To quote RFC 9000 a bit, in section 2.4

On the receiving part of a stream, an application protocol can ... abort reading of the stream and request closure, possibly resulting in a STOP_SENDING frame

And from 19.5

An endpoint uses a STOP_SENDING frame (type=0x05) to communicate that incoming data is being discarded on receipt per application request. STOP_SENDING requests that a peer cease transmission on a stream.

Hence, I agree with MT. The intents of sender and receiver are slightly different. I don't worry too much if the QUIC stack delivers bytes to an application that then get immediately ignored, that already happens in stacks.

If we go with something like Kazuho suggests, "sender MUST NOT reduce Reliable Size and deliver data up to that size" then the consideration we might want to make is that reliably delivering a large amount of bytes after a STOP_SENDING might waste connection resources in spite of the receiver applications intent (and maybe that is already said somewhere?)

[marten-seemann]

Does STOP_SENDING indicate: a) that the receiver has read all data on that stream that the receiver needed, or b) that the receiver is hoping for the sender to stop once the sender sends necessary data as required by the application protocol?

IIUC, WebTransport over HTTP/3 assumes b. Even for a stream on which a STOP_SENDING frame has been received, the sender has to send the first quic int.

I think WebTransport is fine with a. WebTransport can only reset a stream once it has read the stream header and determined that it's a WebTransport stream for that session. By that time, the stream header has already been parsed, so there's no need to retransmit them reliably.

[kazuho]

@marten-seemann Thanks, so you are saying that

• WebTransport receivers MUST NOT send STOP_SENDING until they receive the Session ID (i.e., first quic int), and
• WebTransport depends on Reliable Reset entirely because, when the sender resets a stream on its own discretion, it needs to ensure that the Session ID is delivered to the receiver.

That interpretation works for me (and probably it aligns better with QUIC v1 that allows receivers to stop surfacing received stream data the moment it sends STOP_SENDING).

Based on this, the answer to the original question of this issue would be that the sender can send RESET_STREAM_AT with any Reliable Size between 0 to the Reliable Size that it has previously sent. And RESET_STREAM is also allowed, as RESET_STREAM is equivalent to RESET_STREAM_AT with a Reliable Size of 0.

[marten-seemann]

@marten-seemann Thanks, so you are saying that

* WebTransport receivers MUST NOT send STOP_SENDING until they receive the Session ID (i.e., first quic int), and

I'm saying WebTransport receiver CANNOT send STOP_SENDING, as there's no WebTransport session that could do that.
That said, the HTTP/3 stack MAY send a STOP_SENDING.

Based on this, the answer to the original question of this issue would be that the sender can send RESET_STREAM_AT with any Reliable Size between 0 to the Reliable Size that it has previously sent. And RESET_STREAM is also allowed, as RESET_STREAM is equivalent to RESET_STREAM_AT with a Reliable Size of 0.

I agree with your conclusion. There's no reason to send a value larger than 0 (you're just wasting bytes), but I don't see why would we need to prohibit that either.