Because there is no negative window update on an h2 stream and we give foreground tabs more bandwidth easily with this.

This bubbles down to transaction's initrwin which is then read in Http2Stream::AdjustInitialWindow and leaves the |bump| at zero.

Comment on attachment 8896218 [details] [diff] [review] v1 Review of attachment 8896218 [details] [diff] [review]: ----------------------------------------------------------------- jason isn't the right reviewer here. This is really a question for dragana, myself, or nick.. This is just too aggressive (a 100x decrease) and can certainly lead to issues with stalled windows on high BDP connections. to do 100mbit/sec on 150ms of rtt (which is on the extreme edge of what we want) you would need ~2MB of window. If you set this to 3MB can you get the throttling effect you're looking for?

(In reply to Patrick McManus [:mcmanus] from comment #2) > Comment on attachment 8896218 [details] [diff] [review] > v1 > > Review of attachment 8896218 [details] [diff] [review]: > ----------------------------------------------------------------- > > jason isn't the right reviewer here. This is really a question for dragana, > myself, or nick.. Nick's on PTO, Dragana is busy and you seems to be busy lately, so I gave this to Jason > > This is just too aggressive (a 100x decrease) and can certainly lead to > issues with stalled windows on high BDP connections. > > to do 100mbit/sec on 150ms of rtt (which is on the extreme edge of what we > want) you would need ~2MB of window. If you set this to 3MB can you get the > throttling effect you're looking for? No idea. I was more thinking in h1 dimensions here for which I have some feeling that our 0.75MB pipe is too large when h1 throttling is engaged (we read it out too quickly when the unthrottle tick fires). Maybe I don't know how the h2 windows work exactly. I was quite surprised we have 12MB by default. Most of the tracking resource are extremely small so I'm not sure we can do any throttling at all on them with such large windows. 3MB is no throttling IMO, but as I said, maybe I just don't know how this actually works. If I add a preference for the throttled init window size, would you otherwise accept the patch?

the 12MB default window is meant to ensure it isn't the bottleneck - its bigger than necessary to ensure that. But you want it to be the bottleneck when throttling is engaged, so its a lot trickier. The #1 concern here is to not regress existing uses to accommodate the new feature. So careful measurement is going to be necessary. One thing to note is that in h1 the TCP window is kind of opaque to firefox (and is incremental to the pipe buffer). That's not such a concern in h2. I would think the throttleable target is really downloads, right? For small objects like TP your only really option is to not start them.. (well, they can use this code but I agree its a nop). But downloads are tricky.. we do want to throttle them, but when they aren't throttled they need to run a full (high) bandwidth and that unfortunately means significant window so I'm nervous about clamping it down by default. The right answer here is probably some kind of auto-tuning for a throttleable stream to make it more responsive. Dragana would be the expert, but a crude approach would be to start with a modest number (512KB?), and increase/decrease it based on estimates of the BDP

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Moving to p3 because no activity for at least 1 year(s). See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information