Works for me!

@kazuho -- My point was about convergence to a fair share, since the multiplicative increase will cause the system to move slower towards equal shares.

@janaiyengar

Theoretically, this will have slightly reduced convergence speed than Reno

I'm not sure if I follow this. The effect of additive component is going to be equivalent for both Reno and Pico. Therefore, I presume that the convergence speed of the two algorithms will be the same. Though Pico will experience more loss events when the BDP is high (which is an intentional behavior).

Closing in favor of #470.

Adds a flag called highbdp_mode that changes the increase ratio.

The increase ratio of ordinary Reno is 1 mtu per round-trip (i.e. CWND being acked).

When in high-BDP mode, the CC uses exponential increase during congestion avoidance phase, where the increase rate is calculated so that it would reach the send rate at which the loss was observed every ~1 second. This is roughly equal to what Cubic does.

See https://github.com/h2o/quicly/pull/470.

This PR has been merged, but please let me know if you have suggestions regarding the name.

This is a tiny CC which is a conceptual purification of #469.

The algorithm is dead simple: increase per every byte being acked is calculated as 1mtu/cwnd + (is_slow_start ? 1 : (1/beta -1) * rtt). Beta is 0.5.

The only mode that we have is the is_slow_start flag, that only changes the multiplicative coefficient. There's nothing like choosing a better value from two.

Regarding the formula, 1mtu/cwnd is the increase ratio of traditional Reno during congestion avoidance phase. (1/beta - 1) * rtt is the exponential increase used during the congestion avoidance phase in the highbdp reno variant; for details, see #469.

The key observations regarding this CC are:

• For convergence, use an increase policy that has an additive component and an multiplicative component, as suggested by the Chiu & Jain paper in 1989 (see proposition 1 on p.9).
• During congestion avoidance, when the recovery period of traditional Reno (that is proportional to flow_rate * RTT²) is small, we do slightly better than traditional Reno, because in addition to doing the addtive increase, the "base" being the multiplicative part shoots up by 2x within 0.4~1 second.
• During congestion avoidance, when the recovery period of traditional Reno is large, we do much better than traditional Reno, because thanks to the multiplicative part, we shoot up to the original rate within 1 second, provided that the RTT is below 1 second.
• During slow start, the CWND is increased by 2x + 1 per round-trip, as the paper says that we should have an additive component. Though we can remove it if we want to do what Reno / Cubic has done.

Compared to our Reno that uses beta 0.7, this CC is superior in sense that:

• When the recovery period is small, it is not as aggressive as our Reno. The problem with our Reno is that it is overaggressive compared to ordinary Reno or linux's implementation of Cubic that essentially falls back to Reno when the recovery period is small (am I correct, @janaiyenger?).
• When the recovery period is big, it is more agressive than our Reno due to the same reasons as high-bdp Reno (#469).

Compared to high-bdp Reno (#469), this CC is superior in sense that:

• It follows the recommendation by the paper.
• There's no logic like picking the more aggressive increase value among the two during congestion avoidance.

Some micro experiments:

The logs below shows CWND reduction events from one short distance connection (Tokyo-Tokyo) and a long distance connection (Tokyo-Johannesburg), transferring data at full speed for 15 seconds. Each log line shows the time, CWND post-reduction, and RTT.

Because the buffer size of the bottleneck is as large as ~190ms, all of the runs showed transfer speed of ~35Mbps.

However, as is evident from these traces, Reno does not observe losses once it finishes ramping down to the correct value post slow start. These are proofs that Reno is fragile to random losses / shallow buffers in high BDP connections.

Compared to that, Pico is periodically testing the peek, between every 1 to 2 seconds in both short and long distance connections.

short reno:
**** 1624580413867 - quicly_cc_reno_on_lost:71 cwnd=1506445,rtt=187
**** 1624580414203 - quicly_cc_reno_on_lost:71 cwnd=1054511,rtt=201
**** 1624580414519 - quicly_cc_reno_on_lost:71 cwnd=739053,rtt=203

short pico:
**** 1624580623553 - quicly_cc_reno_on_lost:71 cwnd=1498560,rtt=180
**** 1624580623891 - quicly_cc_reno_on_lost:71 cwnd=1083936,rtt=204
**** 1624580624198 - quicly_cc_reno_on_lost:71 cwnd=784739,rtt=210
**** 1624580625451 - quicly_cc_reno_on_lost:71 cwnd=816325,rtt=205
**** 1624580626575 - quicly_cc_reno_on_lost:71 cwnd=808867,rtt=205
**** 1624580627761 - quicly_cc_reno_on_lost:71 cwnd=813502,rtt=207
**** 1624580628853 - quicly_cc_reno_on_lost:71 cwnd=797931,rtt=203
**** 1624580630073 - quicly_cc_reno_on_lost:71 cwnd=812119,rtt=205
**** 1624580631213 - quicly_cc_reno_on_lost:71 cwnd=806819,rtt=206
**** 1624580632329 - quicly_cc_reno_on_lost:71 cwnd=795941,rtt=199
**** 1624580633519 - quicly_cc_reno_on_lost:71 cwnd=806246,rtt=196
**** 1624580634678 - quicly_cc_reno_on_lost:71 cwnd=812564,rtt=202
**** 1624580635800 - quicly_cc_reno_on_lost:71 cwnd=800858,rtt=200
**** 1624580636982 - quicly_cc_reno_on_lost:71 cwnd=809688,rtt=204
**** 1624580638107 - quicly_cc_reno_on_lost:71 cwnd=799741,rtt=203
**** 1624580639320 - quicly_cc_reno_on_lost:71 cwnd=813386,rtt=205

long reno:
**** 1624581697081 - quicly_cc_reno_on_lost:71 cwnd=3722233,rtt=566
**** 1624581698163 - quicly_cc_reno_on_lost:71 cwnd=2605563,rtt=567

long pico:
**** 1624581518444 - quicly_cc_reno_on_lost:71 cwnd=3396288,rtt=561
**** 1624581519520 - quicly_cc_reno_on_lost:71 cwnd=2699961,rtt=553
**** 1624581520942 - quicly_cc_reno_on_lost:71 cwnd=2509108,rtt=576
**** 1624581522545 - quicly_cc_reno_on_lost:71 cwnd=2492887,rtt=578
**** 1624581524167 - quicly_cc_reno_on_lost:71 cwnd=2480636,rtt=578
**** 1624581525813 - quicly_cc_reno_on_lost:71 cwnd=2491773,rtt=573
**** 1624581527418 - quicly_cc_reno_on_lost:71 cwnd=2481649,rtt=578
**** 1624581529063 - quicly_cc_reno_on_lost:71 cwnd=2490690,rtt=580
**** 1624581530668 - quicly_cc_reno_on_lost:71 cwnd=2482683,rtt=576
**** 1624581532292 - quicly_cc_reno_on_lost:71 cwnd=2480662,rtt=580
**** 1624581533931 - quicly_cc_reno_on_lost:71 cwnd=2480143,rtt=578

"multiplicative"

What's MULT stand for?

The test sometimes fails spuriously because curl requests end up being interleaved

    not ok 1

    #   Failed test at t/50access-log.t line 63.
    #
'GET::/query?abc=d::HTTP/1.1::127.0.0.1:41975::default'
    #     doesn't match
'(?^:^GET::/::HTTP/1\.1::127\.0\.0\.1:[0-9]+::default$)'
    not ok 2
    1..2
not ok 5 - ltsv-related
    # Subtest: timings
        # Subtest: http1

    #   Failed test at t/50access-log.t line 63.
    #                   'GET::/::HTTP/1.1::127.0.0.1:41975::default'
    #     doesn't match
'(?^:^GET::/query\?abc=d::HTTP/1\.1::127\.0\.0\.1:[0-9]+::default$)'
    # Looks like you failed 2 tests of 2.