Add configurable HTTP/2 connection window size

[arturobernalg]

This change adds a local HTTP/2 connection window size setting to H2Config.
The new setting controls connection-level flow control only. It does not affect stream INITIAL_WINDOW_SIZE and preserves the current behavior by default.

[ok2c]

@arturobernalg What is exactly the intent of this change-set? Why do you want this to be configurable? What is the exact use case for this?

[arturobernalg]

@arturobernalg What is exactly the intent of this change-set? Why do you want this to be configurable? What is the exact use case for this?

@ok2c
The intent is to make the connection-level receive window configurable independently of the stream initial window.
The use case is multiplexed H2 connections receiving large bodies, where per-stream windows alone do not bound total in-flight DATA for the connection.

[ok2c]

@arturobernalg Please provide an integration test or a demo app showing that tinkering with this parameter produces any tangible results.

[arturobernalg]

@arturobernalg Please provide an integration test or a demo app showing that tinkering with this parameter produces any tangible results.

@ok2c Added a demo app that keeps the per-stream initial window fixed and varies only the connection-level receive window while transferring many large responses over a single H2 connection.

[ok2c]

@arturobernalg what kind of improvement are you seeing?

[ok2c]

@arturobernalg And more importantly, why would anyone in their sane mind use any value other than MAX?

[arturobernalg]

@ok2c
The point of the option is independent control of connection-level inbound flow. MAX remains a sensible throughput-oriented default. Smaller values are for applications that want stricter aggregate backpressure across all active streams on a multiplexed connection.

A concrete use case is an H2 client in a gateway, proxy, or sidecar multiplexing many large upstream responses over a single connection. Such clients may still want a reasonably large per-stream window, while limiting aggregate inbound data in flight at the connection level.

[arturobernalg]

@ok2c The point of the option is independent control of connection-level inbound flow. MAX remains a sensible throughput-oriented default. Smaller values are for applications that want stricter aggregate backpressure across all active streams on a multiplexed connection.

A concrete use case is an H2 client in a gateway, proxy, or sidecar multiplexing many large upstream responses over a single connection. Such clients may still want a reasonably large per-stream window, while limiting aggregate inbound data in flight at the connection level.

To my mind, the main use case is a gateway, proxy, sidecar, API aggregator, or backend-to-backend H2 client multiplexing many concurrent large upstream responses over a single connection.
Such clients may want to keep the per-stream window reasonably large, while limiting aggregate inbound data in flight at the connection level for tighter backpressure and more predictable resource usage.

[ok2c]

@arturobernalg My daughter was absolutely convinced she really needed a pony when she was 7.

Is there a single user for this parameter? Anyone asked for it? Do you need it for your personal project? For any more or less serious use case this single parameter would likely not be enough. We would likely need a proper strategy interface here if actually anyone really asked for a feature like this.

[arturobernalg]

@arturobernalg My daughter was absolutely convinced she really needed a pony when she was 7.

Is there a single user for this parameter? Anyone asked for it? Do you need it for your personal project? For any more or less serious use case this single parameter would likely not be enough. We would likely need a proper strategy interface here if actually anyone really asked for a feature like this.

For the record. No one asked for AI either, and yet we got OpenAI.

[ok2c]

and yet we got OpenAI.

@arturobernalg Which is bloody shame

[arturobernalg]

and yet we got OpenAI.

@arturobernalg Which is bloody shame

and yet we got OpenAI.

@arturobernalg Which is bloody shame

@ok2c - Agree 100%