Support dynamic flow control window in HTTP/2
- Dominant language
- Java
- Stars
- 4.1k
- Forks
- 2k
- Avg merge
- 3d 56m
- Merged PRs (30d)
- 48
Description
**Jetty version(s)**
12.1.x
**Problem**
Currently, when using `HTTP2ServerConnectionFactory`, we can configure `initialSessionRecvWindow` (default 1 MB) and `initialStreamRecvWindow` (default 0.5 MB). Assuming a 100ms latency, the bandwidth for the entire HTTP/2 session is limited to 10 MB/s, and the per-stream bandwidth to 5 MB/s. As a result, we must know our network characteristics in advance to configure these parameters properly.
**Proposal**
gRPC implementation for go and java has an [BDP estimation and dynamic flow control window](https://grpc.io/blog/grpc-go-perf-improvements/#bdp-estimation-and-dynamic-flow-control-window). Would it be a good idea to support the same algorithm for both client and server?
Contributor guide
Research direction
Start with HTTP2ServerConnectionFactory and review how initialSessionRecvWindow and initialStreamRecvWindow are configured for client and server connections. Compare the proposed behavior with the linked gRPC BDP estimation and dynamic flow-control approach, then define the algorithm's scope and measurable completion criteria before implementation.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- grpc, java
- Domain
- networking
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100