Adaptive reordering thresholds

[ghedo]

This implements adaptive reordering threshold as suggested in:
https://quicwg.org/base-drafts/draft-ietf-quic-recovery.html#section-5.1.1.

The algorithm is similar to what Chrome uses as well.

I did a quick test on my laptop with netem delay 10ms 1ms 10% and this seems to improve things a fair amount:

Before:

finished in 31.92s, 0.03 req/s, 321.44KB/s
requests: 1 total, 1 started, 1 done, 1 succeeded, 0 failed, 0 errored, 0 timeout
status codes: 1 2xx, 0 3xx, 0 4xx, 0 5xx
traffic: 10.02MB (10506459) total, 97B (97) headers (space savings 47.57%), 10.00MB (10485760) data

After:

finished in 1.85s, 0.54 req/s, 5.40MB/s
requests: 1 total, 1 started, 1 done, 1 succeeded, 0 failed, 0 errored, 0 timeout
status codes: 1 2xx, 0 3xx, 0 4xx, 0 5xx
traffic: 10.00MB (10488607) total, 97B (97) headers (space savings 47.57%), 10.00MB (10485760) data

Though we will need more rigorous tests in lab. In particular, I'm not super confident the code to undo the cwnd update is correct. We will also need a time reordering unit test.

This depends on #468 and #469.

[junhochoi]

I think we need to add a new hook (e.g. cwnd_undo()) at CongestionControlOps because when we need to undo cwnd, there can be CC-dependent state changes as well. e.g. in CUBIC I'd like to reset w_max when it happens. e.g. linux tcp has undo_cwnd as a cc hook.

[junhochoi]

I think we can use some of existing experiences -- I was working on a similar work (better to coordinate)

• packet threshold: TCP-NCR(RFC4653) defines a new Limited Transmit. (mentioned in quicwg/base-drafts#3572) While I think TCP-NCR itself is not much useful for QUIC, but the idea of changing dupthresh up to flightsize/MSS -- which means we can remove hard coded MAX_PACKET_THRESHOLD), allowing pkt_thresh up to flight_size/MAX_DATAGRAM_SIZE
• delay threshold: RACK (https://tools.ietf.org/html/draft-ietf-tcpm-rack-08) mentions how to detect and define a delay threshold for reordering. I'd prefer to implement RACK's RACK_update_reo_wnd() which is gradually increasing reordering threshold delay instead of using fixed 5/4 x RTT. QUIC recovery draft already includes many idea of RACK but not this part.

[junhochoi]

I did a quick test on my laptop with netem delay 10ms 1ms 10% and this seems to improve things a fair amount:

Have you tested with netem reorder..?

[ghedo]

Rebased and updated based on #893.

[junhochoi]

I think we still need to tune the algorithm (or threshold. ideally we need to increase a time/packet threshold based on the previous state) for some case (e.g. in a high bandwidth, the benefit is lower), but still better when there is a reodering happening. 👍