@kazu-yamamoto I don't understand this fix. We start with a situation like this:

                rxfBufSize
       |------------------------|
-------------------------------------->
       ^                  ^     ^
  rxfConsumed             |  rxfLimit
                     rxfReceived
                          

                          |-----|
                         available    

where available < rxfBufSize / 2. We now shift the window:

                                  rxfBufSize
                          |------------------------|
---------------------------------------------------------------->
                          ^      ^                  ^
                          |      |            new  rxfLimit
                     rxfReceived |
                     rxfConsumed |
                             old limit
                          

                                 |------------------|
                                      winUpdate    

So

• We know that available < rxfBufSize / 2, therefore
• winUpdate > rxfBufSize / 2, which means that the check if
• winUpdate > rfxBufSize / 8 must definitely be true.

@edsko In the case above, winUpdate is large.
So, this is not the case which we are trying to solve.

Consider another case where you saw a small value of window update with the cold code.
The old code announces it.
The new code delays the announce and waits for the timing of winUpdate > rfxBufSize / 8.

Sorry, I still don't understand :) Doesn't available < threshold already guarantee that the window update must be large? I guess I must be missing something :)

available < threshold guarantees that the first window update is delayed until the half of the received buffer is filled by peer. That's it. I does not guarantee that the next or later window updates are large.

After applying this patch, do you still see any window updates of small values?

Never mind. Probably you are right. I need to think this issue more.

@edsko First of all, please test this patch and check if your issue is fixed. I think this is a correct fix.

You assume that rxfConsumed is equal to rxfReceived in your second picture.
Such a case is very rare.
Many cases follow the example in the documentation.

--                 rxfBufSize
--        |------------------------|
-- -------------------------------------->
--        ^            ^           ^
--   rxfConsumed   rxfReceived  rxfLimit
--                     |01234567890|
--
-- In the case where the window update should be informed to the peer,
-- 'rxfConsumed' and 'rxfLimit' move to the right. The difference
-- of old and new 'rxfLimit' is window update:
--
--                   rxfBufSize
--          |------------------------|
-- -------------------------------------->
--          ^          ^             ^
--     rxfConsumed rxfReceived    rxfLimit
--                     |0123456789012| : window glows

winUpdate is the trailing "12" which can be small in old code.

@kazu-yamamoto We have studied this PR again and we understand it better now. Perhaps it could be simplified if we base the decision to send a window update only on the amount of consumed data, and send a window update when we have consumed at least half of the window size (rather than 1/8th).

Either way, it is reducing the number of window updates. The simplification suggested above might just reduce them even further.

Thanks.
I will merge this and release a new version.
Please send me a PR when you find better parameters or an algorithm based on your operation!