Proposal: Remove Connection Wide Flow Control from QUIC

[Nick Banks <[e-mail]>]

Hey Folks,

After a lengthy discussion on Slack with a few folks I've become convinced that connection flow control is unnecessary to achieve desired over the wire results, causes unnecessary protocol complexity (synchronizing on stream reset) and creates possible deadlocks if the app doesn't behave correctly (won't drain stream A until it receives what it wants on stream B).

The main reason folks seem to think that connection flow control would be useful is DoS protection; to limit the total memory to allocate for one connection. That doesn't seem right to me. A client can open any number of connections. Imposing an overall limit per connection doesn't really work. On the other hand if you only allocate stream flow control if you have enough over all memory (and are draining the data fast enough) then you can better control your memory usage over all connections.

Also, you still have flow control on the number of streams you allow the peer to create as well. That's another connection-wide flow control value. I think it would be an improvement to the protocol if we removed explicit connection wide flow control. If anyone has any other reasons for keeping it, I'd really like to hear them.

Now, I know this is late in the game and not strictly a necessary change. You can still just ignore connection flow control on the sender side and achieve the same thing; so this might not meet the bar. I just wanted to have this discussion and see what other folks think about this. If most folks agree that it's not necessary, I don't think it should be too big a deal to remove both the text and implementation code.

Thanks,
- Nick