Consider implementing connection level flow control
We currently do not implement connection level flow control, but instead simply grant the remote an excessively large connection level send window:
https://github.com/mozilla/neqo/blob/fab0046d2556eb6603c2354552a025d8ee0b782f/neqo-transport/src/connection/params.rs#L30
If we had connection level flow control, we could use its bandwidth-delay product estimate to bootstrap the receive window of a new stream flow control. The sender would thus be able to use the full bandwidth of the connection on that single stream early on.
Originally raised in:
As for the follow-up idea, having connection-level flow control would be nice because it allows us to estimate actual BDP usage, not availability with overheads. If we had that, then it might be easier to produce estimates for things like WebTransport throughput availability estimates.
Originally posted by @martinthomson in https://github.com/mozilla/neqo/pull/1868#pullrequestreview-2728125376