ambiguity on reaction to RST_STREAM

[mirjak]

The transport draft leaves it currently open to the receiver to delivery outstanding and newly received data to the application after RST_STREAM was received. This introduces some ambiguity for flow control (see section "Edge Caeses and Other Considerations"). Further it may incentive wrong use of RST_STREAM and provide unepxected behavior between different quic implementation ("I always used RST here and data was correctly delivered...").

I would recommend to clearly specify that all data must be immediately dropped if RST_STREAM is received because that should only be send in an error case where that data is not useful anymore anyway.

(Effectly you don't even need the final offset in the RST_STREAM frame in that case anymore, but I guess that doesn't hurt.)

[mikkelfj]

You need the offset to account for flow control credits against global data limits. If the stream always ends at a given offset, RST or FIN, how is that ambigous?

[mirjak]

If you drop all data on receive of RST of that stream, you don't need to count any of that data for flow control.

It's ambiguous because currently the receiver can decide to drop and not count it, or to keep it and count, so both ends may be out of sync, as explained on the "Edge Caeses and Other Considerations" section.

[mikkelfj]

OK, maybe I'm not up to speed on the spec then.

But as I see it, anything you send on a stream counts as sent whether you later decide to RST or FIN. You have used capacity on the wire. The fact that you do not care about the data any more is just a sunk cost, just as if you bought a concert ticket and got sick.

[mirjak]

Actually, sorry you are right, you still need the final offset.

However, what this is ambiguous is if data gets delivered to the application or not.

[mikkelfj]

Yes, delivery is ambigous but that is not necessarily a bad thing. Ordered delivery isn't even required so you could have deliver some post gap data before seeing a RST - for some application that is a feature. This behaviour is better specified at the application protocol level, but I think a recommended default is in place. For deliver, the recommended behavior is to be in order, by default, I believe.

[MikeBishop]

This is actually very like what we wrestled with in #1643.

Consider the extreme case and work backward:

• RST_STREAM is received after application has already read the entire stream data. Application might not ever realize there was a RST -- it's already consumed everything and moved on.
• RST_STREAM is received after transport has received all data, but application hasn't read it to completion. You can either surface all the data to the application (turns into previous case) or drop the unread data and begin returning a read error.
• RST_STREAM is received while data is outstanding. You can either surface the error when the application's reads hit a gap, or drop the unread data and begin returning a read error immediately.

Frankly, I'm comfortable with that being an implementation decision. When you send a RST_STREAM, you're accepting some ambiguity about exactly what makes it to the other side. In HTTP, we resolved that by saying that if you've potentially sent enough data for the other side to act on and you don't want to see the response, you need to send a STOP_SENDING at the same time.

[martinthomson]

The important point here is that there is no ambiguity about flow control. If you send data, it counts. If you claim to have sent data (by setting an offset in RST_STREAM), it counts.

Yes, as a sender, you don't necessarily know what the recipient did (absent mechanisms like we have for QPACK), but that's OK: you send RST_STREAM, you give up any rights to knowing what happens to data on that stream because it's an explicit signal saying you don't care.