Flow control protocol redundancy

A connection and all its streams have independent flow control windows. All their initial window sizes are equal, and updated simultaneously by the SETTINGS frame. However, slack must be restored to each window independently by WINDOW_UPDATE frames.

Connection-wide WINDOW_UPDATE frames introduce redundancy and a potential source of protocol errors. Every byte represented by a stream WINDOW_UPDATE must also be accounted as a connection WINDOW_UPDATE before the slack can be used. Although stream updates contain sufficient information to maintain the connection-wide window, an endpoint must refrain from doing so.

Transmitting the connection WINDOW_UPDATE before that/those of the streams temporarily permits the remote side to transmit on streams with preexisting slack, i.e. whichever streams aren’t active. This potentially leads to priority inversion. Transmitting it after stream updates delays everything. Interleaving connection and stream updates wastes bandwidth.

Why not do away with connection-wide WINDOW_UPDATE frames? Let the stream updates affect the connection window in the same manner as data frames do (but negatively, and upon receipt rather than transmission).

The conceptual sacrifice is that it becomes impossible to define a flow-controlled frame type that is not associated with a stream. But this is currently meaningless, and it seems very reasonable as a future restriction too.

---
On a related note, I don’t see why a window size should ever be allowed to exceed the initial size. FIFO buffers usually have fixed size. Failing to set/update the initial window size renders a receiver incapable of attempting to throttle back connections that might have become overcommitted with expected data. Currently there are two different ways to increase the total window size, with slightly different consequences. Such a redundancy increases the range of remote behaviors to be tested against, and ultimately harms reliability.

Received on Sunday, 23 March 2014 09:50:57 UTC