gRPC HTTP/2 Flow Control: Tuning Window Sizes for High Concurrency Latency

gRPC relies on HTTP/2 flow control to manage data transmission between clients and servers. This mechanism uses a window-based credit system to prevent receivers from being overwhelmed by fast senders. While this ensures stability, the default window sizes may not be optimized for all network topologies, particularly when high concurrency is introduced on a single TCP connection.

Under heavy concurrent loads, the Bandwidth Delay Product (BDP) can lead to window exhaustion. When the available window size is depleted, the sender must wait for window update frames from the receiver, which can introduce latency spikes that are not present during sequential or low-concurrency requests.

Given the differences in how flow control is handled across various transport implementations, such as Netty or C-core:

• What are the specific criteria for determining the optimal initial window size to mitigate concurrency-induced latency?
• How does the interaction between the stream-level and connection-level windows affect throughput when scaling concurrent requests?