From c9452abd085a051120bb187da81253ea9095257b Mon Sep 17 00:00:00 2001 From: Kazuho Oku Date: Tue, 5 Mar 2024 15:10:24 +0900 Subject: [PATCH] talk about latest rtt too --- lib/quicly.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/lib/quicly.c b/lib/quicly.c index 841afbe7..e19276f6 100644 --- a/lib/quicly.c +++ b/lib/quicly.c @@ -3038,10 +3038,11 @@ static uint32_t calc_pacer_send_rate(quicly_conn_t *conn) { /* The multiplier uses a hard-coded value of 2x in both the slow start and the congestion avoidance phases. This differs from * Linux, which uses 1.25x for the latter. The rationale behind this choice is that 1.25x is not sufficiently aggressive - * immediately after a loss event. Following a loss event, the congestion window (CWND) is halved (i.e., beta), but the Smoothed - * Round Trip Time (SRTT) can remain high for a couple of round-trips since it is a moving average adjusted with each ACK - * received. Consequently, if the multiplier is set to 1.25x, the calculated send rate could drop to as low as 1.25 * 1/2 = - * 0.625. By using a 2x multiplier, the send rate is guaranteed to be no less than 1x. */ + * immediately after a loss event. Following a loss event, the congestion window (CWND) is halved (i.e., beta), but the RTT + * remains high for one RTT and SRTT can remain high even loger, since it is a moving average adjusted with each ACK received. + * Consequently, if the multiplier is set to 1.25x, the calculated send rate could drop to as low as 1.25 * 1/2 = 0.625. By + * using a 2x multiplier, the send rate is guaranteed to become no less than that immediately before the loss event, which would + * have been the link throughput. */ return quicly_pacer_calc_send_rate(2, conn->egress.cc.cwnd, conn->egress.loss.rtt.smoothed); }