x/net/http2: Server window updates are too chatty

[hawkinsw]

First, thank you all for the work that you do implementing and maintaining an excellent H2 library! Working with Go to implement a protocol over H2 is an absolute dream because of the work that you do!

In our use case (an implementation of the new proposed IETF RPM protocol for measuring responsiveness under working conditions) we make heavy use of the POST capabilities of the server implementation in H2. What we have noticed is that the Server code is a little too chatty sending per-connection and per-stream window update messages.

We know why this behavior happens. Not that you need to hear this (you implemented it, after all), but for the sake of completeness, here is our understanding:

1. (after lots of initial code executes to initialize a stream [and subsequent to connection initialization]), a pipe (ultimately) connects

• the independently executing go function that reads frames from the wire that the client is sending (this will call the Write method on the pipe); and
• a user-specified handler function that calls Read on the requestBody (this will call the Read method on the pipe)

2. A Read on the pipe blocks on a condition variable that is signaled by the Write side of the pipe whenever data is sent in to the pipe.
3. Because the Write-side of the pipe happens every time a data frame is received, Writes put MaxReadFrameSize (approximately 16k) bytes in to the pipe at a time.
4. For every MaxReadFrameSize bytes put in to the pipe, the condition variable is signaled which
5. ultimately wakes up the Read blocked in the user-supplied handler.
6. Because of how efficient and awesome the go runtime is, the Read usually unblocks before another frame is read from the wire (no matter how fast you can push data along the wire).
7. Therefore, at a max, the user-supplied handler function is only (again, usually) able to successfully read MaxReadFrameSize bytes at a time from the request body (and that is after optimization [NB: In our application we discard the bytes pushed by the server and even io.Discard is too timid in this respect! (yes, I am running out nested bracket sigils!)]).
8. When the user-supplied handler acknowledges the bytes it read from the body of a request, serverConn.noteReadFromBodyHandler is invoked which (ultimately) triggers an unconditional window update for both the stream and the connection.
9. Voila, we arrive at the ultimate behavior that the server implementation of the H2 library sends window updates at increments that are more frequent than 16k.

Whew. Sorry for the word salad! I hope that is legible and reasonable.

According to the H2 spec:

The receiver of a frame sends a WINDOW_UPDATE frame as it consumes data and frees up space in flow-control windows. Separate WINDOW_UPDATE frames are sent for the stream- and connection-level flow-control windows. Receivers are advised to have mechanisms in place to avoid sending WINDOW_UPDATE frames with very small increments; see Section 4.2.3.3 of [RFC1122].

The quoted RFC encourages window updates only be sent when they expand the buffer by 1/2 the window size. [p 98[(https://www.rfc-editor.org/rfc/rfc1122.html#page-98).

We propose that the server implementation of the H2 library be modified to work in this fashion. We are accompanying this proposal (which we hope is following the proper procedures!) with a patch to implement the behavior. The patch does not add additional public APIs -- we think that's a plus.

Again, thank you so much for all the work that you put in to creating and maintaining this excellent library and we hope that this proposal and patch are helpful.

Sincerely,
Will

[hawkinsw]

As promised, here is the corresponding proposed patch: https://go-review.googlesource.com/c/net/+/426414

[seankhliao]

not a proposal as there's no api change

is this the same as #28732 ?

cc @neild

[neild]

Yeah, this is the same as #28732, which I hadn't seen until now. Left a comment on @fraenkel's CL (https://go-review.git.corp.google.com/c/net/+/150197/) as well.

[neild]

Duplicate of #28732.