[quicwg/base-drafts] RST_STREAM and connection-level flow control (#163)

[Martin Thomson <[e-mail]>]

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.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/163