Re: Flow control protocol redundancy

Now I find the thread "WINDOW_UPDATE with streamid = 0 redundant?” from Feb 11. Several arguments are made in this discussion, all flawed:

1. The connection-level window is not the sum of the stream-level windows. Nobody said it was. Absent connection-wide updates, the connection window would be the sum of all the stream-level changes (credits and debits) plus the initial size.

2. Streams may over-advertise their windows, then rely on connection-level updates to finalize the credit transfer. This does not provide any capability, and such practice means that some streams are being throttled, but other streams cannot be throttled until the excess credit is consumed.

3. Common practice is to allow window size to exceed INITIAL_WINDOW_SIZE. We’re in a prototyping phase, and bugs in prototypes do not constitute precedents.

4. A client may wish to accept a stream in a stalled state. The current flow control protocol does not allow this even with abuse. A sender always starts with credit equal to INITIAL_WINDOW_SIZE. Anyway, dependency and (re)-prioritization already provides for this, and with pushes (the mentioned use-case) dependency is the default. If prioritization isn’t working properly, perhaps that protocol needs to be extended.

5. The difference in stream credit may be used to manipulate a proxy. Flow control is a hop-to-hop protocol and it should not be used for end-to-end control. This is likely to pessimize proxy behavior, for example a change only propagates as fast as proxy buffers empty out. The end-to-end prioritization protocol is appropriate.

6. A small initial window is the way to effect 100 CONTINUE. If this is desired, then a small initial window should be the default. Why should the standard require reconfiguration at the low level of flow control to allow a server to support apps which might use the high-level CONTINUE construct? Everyone will be downsizing their windows. Of course there are other means to this end.

Also, I should mention that the idea of over-advertisement reeks of an integer overflow bug. Sloppy accounting leads to accumulated deficits. A server bug that is merely deferred for a long time will be extremely frustrating when it is finally triggered. The current standard seems to grant servers the right to fudge the accounting, but requires clients to abruptly terminate the connection when the “money supply” is exhausted.


In summary, multi-level flow control isn’t really flow control, but emulation of some other features. Since HTTP/2 already has those features, it is still redundant, and furthermore encourages avoidance of more appropriate practices.


P.S. Sorry for the earlier double post, mail client was acting up…

Received on Monday, 24 March 2014 01:03:18 UTC