From: Frederic Lecaille <flecaille@haproxy.com>
Date: Thu, 12 Dec 2024 11:15:31 +0000 (+0100)
Subject: BUG/MINOR: quic: reduce packet losses at least during ProbeBW_CRUISE (BBR)
X-Git-Tag: v3.2-dev2~84
X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=9813de0537882355514794eed7b738bed1806954;p=thirdparty%2Fhaproxy.git

BUG/MINOR: quic: reduce packet losses at least during ProbeBW_CRUISE (BBR)

Upon congestion events (for a instance packet loss),
bbr_adapt_lower_bounds_from_congestion() role is to adapt some BBR internal
variables in relation with the estimated bandwidth (BBR.bw).

According to the BBR v3 draft, this function should do nothing
if BBRIsProbingBW() pseudo-code returns true. That said, this function
is not defined by the BBR v3 draft. But according to this part mentioned before
defining the pseudo-code for BBRAdaptLowerBoundsFromCongestion():

4.5.10.3. When not Probing for Bandwidth
When not explicitly accelerating to probe for bandwidth (Drain, ProbeRTT,
ProbeBW_DOWN, ProbeBW_CRUISE), BBR responds to loss by slowing down to some extent.
This is because loss suggests that the available bandwidth and safe volume of
in-flight data may have decreased recently, and the flow needs to adapt, slowing
down toward the latest delivery process. BBR flows implement this response by
reducing the short-term model parameters, BBR.bw_lo and BBR.inflight_lo.

BBRIsProbingBW() should concern the accelerating probe for bandwidth states
which are BBR_ST_PROBE_BW_REFILL and BBR_ST_PROBE_BW_UP.

Adapt the code to match this latter assumption. At least this reduce
drastically the packet loss volumes at least during ProbeBW_CRUISE.

As an example, on a 100MBits/s internet link with ~94ms as RTT, before
this patch, 4329640 sent packets were needed with 1617119 lost packets (!!!) to
download a 3GB object. After this patch, 2843952 sent packets vs 144134 lost packets
are needed. There may be some packet loss issue. I suspect the maximum bandwidth
which may be overestimated. More this is the case, more the packet loss is big.
That said, at this time, it remains below 5% depending on the size of the objects,
5% being for more than 2GB objects.

Must be backported to 3.1.
---

diff --git a/src/quic_cc_bbr.c b/src/quic_cc_bbr.c
index fb5c23e757..f2008edf6a 100644
--- a/src/quic_cc_bbr.c
+++ b/src/quic_cc_bbr.c
@@ -1026,9 +1026,15 @@ static void bbr_loss_lower_bounds(struct bbr *bbr)
 	                       bbr->inflight_lo * BBR_BETA_MULT / BBR_BETA_DIVI);
 }
 
+static inline int bbr_is_accelerating_probing_bw(struct bbr *bbr)
+{
+	return bbr->state == BBR_ST_PROBE_BW_REFILL ||
+		bbr->state == BBR_ST_PROBE_BW_UP;
+}
+
 static void bbr_adapt_lower_bounds_from_congestion(struct bbr *bbr, struct quic_cc_path *p)
 {
-	if (bbr_is_probing_bw(bbr))
+	if (bbr_is_accelerating_probing_bw(bbr))
 		return;
 
 	if (bbr->loss_in_round) {