On Tue, Jan 23, 2018 at 2:13 PM, klzgrad <[email protected]> wrote:
> This tuning knob is probably only useful if it's also applied to the
> overall connection windows in addition to stream windows.
This should be fairly easy to do:
--- a/src/mux_h2.c 2017-12-31 01:13:19.000000000 +0800
+++ b/src/mux_h2.c 2018-01-24 21:45:41.089380260 +0800
@@ -399,7 +399,7 @@ static int h2c_frt_init(struct connectio
h2c->max_id = -1;
h2c->errcode = H2_ERR_NO_ERROR;
h2c->flags = H2_CF_NONE;
- h2c->rcvd_c = 0;
+ h2c->rcvd_c = some_initial_connection_window_size -
h2_settings_initial_window_size;
h2c->rcvd_s = 0;
h2c->nb_streams = 0;
The problem is the window size for the connection probably has to use
a different value.
Bad things happen with the current default 65535 window size for both
the connection and streams. One upload stream is able to use up the
connection window size and stall all other streams (at least this is
what Chromium does).
So the connection window size should be at least 2x the stream window
size. Things become more complicated if one considers packet losses of
WINDOW_UPDATEs:
- one WINDOW_UPDATE lost.
- X00 ms later, retransmission of WINDOW_UPDATE.
- During the X00 ms the connection flow-control prevents sending
anything because HTTP/2 says so not because TCP is actually having
problem sending stuff.
Okay, for one lost WINDOW_UPDATE we can add one or two extra round
trips to window size calculation. What about multiple losses?
At this point I wonder what is the point of having HTTP/2
connection-level flow-control on top of TCP connection flow control?
For throttling there's other knobs to use. I would use 2^31-1 for the
connection window size.
-klzgrad
