Configure HTTP/2 receive window size

[CarnaViire]

Background and Motivation

Current HTTP/2 receive window size is 64 Kb, which is too small for many scenarios. It leads to poor throughput, see e.g. #43086

Just increasing the default window size may result in unwanted memory consumption in some cases. It is proposed to enable users to configure flow control properties that so they can reach a compromise between memory consumption and throughput.

Proposed API

public sealed partial class SocketsHttpHandler
{
    ...
    public bool EnableMultipleHttp2Connections { get; set; }
+   public int InitialHttp2ConnectionWindowSize { get; set; }
+   public int InitialHttp2StreamWindowSize { get; set; }
+   public int Http2StreamWindowUpdateRatio { get; set; }
}

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Background and Motivation

Current HTTP/2 receive window size is 64 Kb, which is too small for many scenarios. It leads to poor throughput, see e.g. #43086

Just increasing the default window size may result in unwanted memory consumption in some cases. It is proposed to enable users to configure that so they can reach a compromise between memory consumption and throughput.

Proposed API

public sealed partial class SocketsHttpHandler
{
    ...
    public bool EnableMultipleHttp2Connections { get; set; }
+   public int InitialHttp2StreamWindowSize { get; set; }
}

Author:	CarnaViire
Assignees:	-
Labels:	api-suggestion, area-System.Net.Http
Milestone:	6.0.0

[halter73]

How is the initial connection window size currently determined? Should that also be configurable?

[CarnaViire]

Connection's window size is 64 Mb. I guess configuring it makes sense, in case you would want a really big stream window, so connection window won't become a bottleneck... I'll add that

[ManickaP]

Should we also consider the size of the increments?
https://github.com/dotnet/runtime/blob/main/src/libraries/System.Net.Http/src/System/Net/Http/SocketsHttpHandler/Http2Stream.cs#L91
We're now using 1/8 of the window size, whereas Kestrel is using 1/2 (if I understand it right):
https://source.dot.net/#Microsoft.AspNetCore.Server.Kestrel.Core/Internal/Http2/Http2Stream.cs,62

So to achieve similar window update sizes (32KB) one would need to raise this value 4x to 256KB...

[JamesNK]

Are these configuration settings designed to allow good performance by default, or are they for advanced users to tune performance?

I believe the HTTP/2 functionality in Grpc.Core (which uses a C++ HTTP/2 stack) has good performance without having to tune this configuration. Ideally SocketsHttpHandler would be the same.

If we make devs change these settings, most aren't going to know to and will continue to have HTTP/2 perf issues with large requests.

[CarnaViire]

@JamesNK we intend to update the defaults so it will allow good performance in most of the cases without the need to change anything. The main reason for these settings is to be sure that we will not break/block anyone with our suddenly increased defaults and they could set it to something smaller. And as a second reason we'll have some advanced tuning for those who are interested.

[antonfirsov]

[API] The proposal started with 1 property, now we have 3 :) How would the introduction of the dynamic window algorithm impact this API? Will there be a new bool property to turn it on/off? Are the properties InitialHttp2***WindowSize and Http2StreamWindowUpdateRatio meaningful in that case? Will there be any further properties specific to the dynamic window algorithm?

[CarnaViire]

@antonfirsov all of the properties will make sense even with an introduction of the dynamic algorithm. InitialHttp2***WindowSize will indicate a start from which the window might grow bigger depending on RTT information. Http2StreamWindowUpdateRatio will bear the same meaning it has now, indicating the ratio of the WINDOW_UPDATE size to the full window size, regardless of whether the window size is changing or not.

New properties for turning dynamic algorithm on/off or other configs might appear, however, it's better to discuss them separately when we decide to implement dynamic algorithm.

[antonfirsov]

New properties for turning dynamic algorithm on/off or other configs might appear

In this case, wouldn't it make sense to extract the properties to a separate Http2WindowOptions class now? Alternatively, we can prefix the properties, just like we do with KeepAlivePingDelay + KeepAlivePingPolicy + KeepAlivePingTimeout, but I don't see an good candidate for a prefix here.

Personally, I dislike how SocketsHttpHandler became a long flat list of seemingly unrelated options, it hurts discoverability. @scalablecory do you know why does the design keep evolving this way?