HTTP/2: to many stream window size updates after connection window size update about cowboy

[essen]

Do you have the WINDOW_UPDATE sizes that were sent, both for the connection and each individual streams?

[RoadRunnr]

Do you have the WINDOW_UPDATE sizes that were sent, both for the connection and each individual streams?

Does a PCAP help? The data comes from a load generator that fills it with pseudo random values, therefore no problem sharing it here.

cowboy-h2-window-update.pcapng.gz

• connection window size is exceeded in frame # 199
• connection WINDOW_UPDATE is in frame # 305 and cowboy start sending stream WINDOW_UPDATEs immediately afterwards

The client in this case was gun with default settings.

NOTE: this particular PCAP also has the problem that it exceeded the max_received_frame_rate, but that should not be relevant to the issue.

[essen]

Yes that's perfect, thank you.

Considering the increment, I think it's just Cowboy handlers that have called read_body which defaults to 8MB read body size. Because 8MB is more than the current stream's window, Cowboy increases it preemptively to let the client upload without being blocked. Because many streams try to read bodies at the same time, Cowboy simply has to send many WINDOW_UPDATE frames.

Note that this only happens after the handlers have started calling read_body as Cowboy will not increase the window before to avoid being overloaded, as well as to avoid using resources if the body ends up discarded. This is why you end up with a split DATA frame in 3.

Cowboy does not loop over all streams sending a WINDOW_UPDATE, but each stream may independently send it. It appears weird because of the nature of the test.

In practice you may reduce the size read by read_body to avoid this. If you expect the body to be below, say, 10K, then set that as the length option and WINDOW_UPDATE frames will not be sent.