Response to RST_STREAM is a little unclear.

[martinduke]

In a bidirectional stream, if I receive a RST_STREAM, how am I to know how much of the data I have sent is counting towards connection flow control?

For example, say I send 10 STREAM frames on stream 0, of 1000 B each, receive a RST_STREAM for stream 0 with offset 0, and then acks for packets 1:4 and 6:10. It is clear that I should deduct zero of the credit I am granting to the peer, but it is not clear how much connection credit the peer has deducted for this stream.

One way to solve this is to have a receive offset field in RST_STREAM. When I receive one of these, I can flush the send queue and recover any credit I had taken from myself. In this case, if the RST_STREAM had a max receive offset of 1000, I'd add 9000 back to my connection credit.

Inveterate optimizers might want this field to only exist for bidi streams. I don't particularly care.

[mikkelfj]

Isn't this covered here:
https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#rfc.section.10.1

More generally though - I'm not sure exactly which frames count toward flow control - e.g. what about a lost padding only packet that is never retransmitted? Or extension frames.

[martinduke]

No, the offset field in RST_STREAM addresses only one direction -- the correct final offset from RST_STREAM sender to RST_STREAM receiver. I spent some time trying to figure out if the spec expected me to send RST_STREAM in response to RST_STREAM, and I decided that wasn't the case even though the uni stream state machines sort of imply it.

The final offset from RST_STREAM receiver to RST_STREAM sender is never explicitly communicated, as far as I can tell.

More generally though - I'm not sure exactly which frames count toward flow control - e.g. what about a lost padding only packet that is never retransmitted?

It's STREAM contents only that count. Other frames, like padding, aren't buffered by the receiver.

[RyanTheOptimist]

@mikkelfj Flow controls applies to data sent on streams in the form of STREAM frames. It does not apply to packets or other frame types. So a lost padding frame would have no bearing on flow control.

[mikkelfj]

@RyanatGoogle thanks - I did implement it once, but it was more than a year ago.
@martinduke I see. But (and this is weak memory) I think that each direction is handled separately. Resetting one direction does not terminate the other - the stream just transitions into what was formerly known as a half-open state. Otherwise you are right, it would be a problem, and if not, perhaps the text needs some clarification.

[mikkelfj]

https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#rfc.section.9.2.4
https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#rfc.section.10.1.1
"A bidirectional stream is composed of a send stream and a receive stream. Implementations may represent states of the bidirectional stream as composites of send and receive stream states."
"RST_STREAM terminates one direction of a stream abruptly."

[MikeBishop]

@mikkelfj is correct -- each direction is independent. If you receive a RST_STREAM, the data flowing toward you has ceased abruptly. This does not inherently mean that you cannot respond. If you choose not to respond, send a RST_STREAM yourself, which then contains the flow control information you're discussing.

Is there text we should clarify for this?

[martinduke]

If RST_STREAM begets a return RST_STREAM, that's news to me. If everyone is happy with this state of affairs, I'll file a PR to make that a bit clearer in the spec. (I explicitly looked for this in the spec before filing, and couldn't find it). I suppose it's implied by the state machines and so forth, but this is different from HTTP/2 and probably could be more explicti.

[ianswett]

Yup, that's how it sort of needs to work, since both sides need to communicate an offset, and the two ways are via a FIN'd stream or a RST_STREAM frame.

A PR to clarify that is always helpful.

[martinthomson]

Having just re-read the section on this, I don't agree that there is a problem. The text is very clear on this in Section 4.1, which specifically addresses the interaction of stream cancellation and flow control:

RST_STREAM terminates one direction of a stream abruptly. Whether any action or response can or should be taken on the data already received is an application-specific issue, but it will often be the case that upon receipt of a RST_STREAM an endpoint will choose to stop sending data in its own direction. If the sender of a RST_STREAM wishes to explicitly state that no future data will be processed, that endpoint MAY send a STOP_SENDING frame at the same time.
-- https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#handling-of-stream-cancellation

To answer the question:

In a bidirectional stream, if I receive a RST_STREAM, how am I to know how much of the data I have sent is counting towards connection flow control?

You have to assume ALL of it.

[mikkelfj]

Also note that RST does not require peer RST, the peer can alternatively continue sending data and/or FIN

[martinduke]

Renaming this issue to reflect the real problem, though I guess I'm the only one that was confused. I'll file a small PR to scratch my itch

[martinthomson]

Merged #1893 manually.

[martinthomson]

GitHub is acting out here. Fix merged manually.