RST_STREAM and connection-level flow control

[martinthomson]

RST_STREAM kills a stream, but what impact does it have on connection flow control? Or are we required to account for data in STREAM frames even if they are discarded?

The problem here is that data on reset streams is not re-sent, therefore peers get a very different view about what data has been sent. The receiver of RST_STREAM has no way to manage connection-level flow control for the packets that it has sent. Packets that it sends before receiving the RST_STREAM might be lost and therefore they might or might not have been counted by the other side.

At best, this results in an overly pessimistic view of the connection-level flow control window. Though it could end up freezing the connection if there are lots of RST_STREAM use with concurrent packet loss.

The sender of RST_STREAM can signal the offset of the last octet and thereby ensure that their data is accounted for. (Separately, we need policing for this value: if it indicates that a flow control window was exceeded, we should treat it as such, even if the frames that it mentions were never sent: opened #162.)

A potential fix: require RST_STREAM in both directions. A more drastic fix: make streams unidirectional.

Related to the issue @marten-seemann originally mentioned in #145.

[MikeBishop]

Yes, I think RST_STREAM in response to a RST_STREAM is probably the best solution here. And I think the set of error codes that are in Chrome's code but not in the spec includes an error code for "received RST_STREAM." If you receive a RST_STREAM with any error code other than that one, you MUST generate a RST_STREAM with that error code.

[mnot]

As discussed in Tokyo, not valid anymore