Why is the crypto stream not subject to connection flow control

[siyengar]

IIRC previously this was not done because flow control messages for the connection were sent on the stream 0. However with MAX_DATA frames they are not sent over stream id 0 any more. Having only crypto streams not be subject to connection level flow control creates a bunch of workaround code to check for if (stream == cryptoStream) before you increment the cumulativewritedataoffset for the connection which is used to track conn flow control.

[martinthomson]

The problem is early data and the handshake. It is possible that early data will exhaust the connection flow control window. I fact, that's a feature: we use the connection flow control window to limit the amount of early data, just as there is an early data limit in TLS. If that happens, there is no room to send the client Finished (and Certificate[Verify]). That would block handshake completion, which is bad. Also, the server doesn't really have a good way to send authenticated MAX_DATA frames to the client at this point, so it doesn't easily resolve itself.

Yeah, it's a real pain. Stream 0 is too special for my liking also.

[siyengar]

ya that sounds reasonable, I realized that this might be a reason just after posting :)

[janaiyengar]

Necessary evil. Control channels are as old as the hills -- nothing new here :-)