tree 5132090641ac225a866359280d0595b43f2cc15d
parent 18a682b53ff0d28356cad2fb46f2e5c5ed14820c
author Junho Choi <junho@cloudflare.com> 1589593365 -0700
committer Junho Choi <junho@cloudflare.com> 1603415566 -0700

update the receiver flow control

This PR is to adopt [Chromium's approach]
(https://docs.google.com/document/d/1F2YfdDXKpy20WVKJueEf4abn_LVZHhMUMS5gX6Pgjl4/edit?usp=sharing) for the receiver flow control.

flowcontrol.rs contains a common framework for flow control updates.

Basically, the concept is to keep a `window` / 2 between the consumed
data offset and `max_data`. When the gap is smaller than window / 2,
we update `MAX_DATA` frame. Same applies to the stream updating
`MAX_STREAM_DATA`.

Auto-tuning of the window is also implemented. When `window`
update keeps happening within 2 x rtt, double `window` value.
By this `window` will be close to the actual BDP. Note that
the window only grows, not shrinks.

Also, make sure the connection window is always 1.5x higher
than any of the stream window. This is for making sure that
the connection flow limit is not a blocker for the stream
to grow.

`RecvBuf.push()` now returns the increased size of the last offset,
which will be used for updating `rx_data`. This is actually a bug fix.
Previously we increased `rx_data` by the size of the data received,
however when the data has an overlap (e.g. duplicate packet) we
should not increase `rx_data`. Also `rx_data_consumed` is added for
tracking `rx_data` offset consumed by the application.