BBRv2/v3 详解

昨晚写了 从 BBRv2 到 BBRv3，有些核心点没有说清，剩下的自由两天，继续补充。

不管承认不承认，BBRv2/v3 在事实上已经是 cwnd-based cc，辅助以 pacing control。这没有什么错，我此前一贯的观点也这样，控制 inflight 总量，辅助以 pacing，至于这个 pacing 具体是多少，反正根本测不准，随便一个不大不小的 pacing rate 即可，典型的就是取 delivery rate，或大或小。

BBRv2/v3 与我此前 E_best inflight 守恒算法不同点在于它以 pacing gain 为因子做带宽 Probe 的手段，该行为内置在状态机中，具体参见下面函数：

/* PROBE_BW state machine: cruise, refill, probe for bw, or drain? */
static void bbr_update_cycle_phase(struct sock *sk,
                                    const struct rate_sample *rs,
                                    struct bbr_context *ctx)

本文主要说一些细节。

先看一下 BBRv2/v3(以下简称 BBR) 的 cwnd control 如何起决定性作用。BBR 采用下面的算法界定 cwnd，参见 BBR Congestion Control 4.6.1 节：

可以看到，cwnd 增加了严格的约束，界定在 inflight_lo 和 inflight_hi 之间，cwnd_gain * BDP 仅作为一个下界参与界定：

if (bbr->cycle_idx == BBR_BW_PROBE_CRUISE)
    cap = 0.85 * inflight_hi;
else
    cap = inflight_hi;
cap = min(cap, bbr->inflight_lo);
cap = min(cap, cwnd_gain * maxbw * minrtt);

接下来看一下 inflight_hi，inflight_lo 各自如何获得，这也是 BBRv2/v3 的一个难点。

如果把 BBR 状态机摘掉，用 AIMD 过程取代，inflight_hi 应该是 Additive Increase 的结果，而 inflight_lo 则来自 Multiplicative Decrease。换成 BBR 的 MDMD 过程，无非 BBR_BW_PROBE_UP 产生的 inflight 得到了 inlight_hi，而 Loss 对 inflight 进行 MD 而产生了 inflight_lo，该下界正是如 BBRv2 所述 “对丢包做出响应” 之体现。若没有丢包，inflight_lo 则完全不起作用。

与 AIMD 不同，BBR’s inflight_hi 在 BBR_BW_PROBE_UP phase 是一个增量 Slow-Start 过程(代码后解释)，由于内核不好实现浮点数运算，才导致代码太怪太乱，看注释即可：

// 每一个 round 执行 volume 翻倍。
/* Each round trip of BBR_BW_PROBE_UP, double volume of probing data. */
static void bbr_raise_inflight_hi_slope(struct sock *sk)
{
    /* Calculate "slope": packets S/Acked per inflight_hi increment. */
    growth_this_round = 1 << bbr->bw_probe_up_rounds;
    bbr->bw_probe_up_rounds = min(bbr->bw_probe_up_rounds + 1, 30);
    cnt = tcp_snd_cwnd(tp) / growth_this_round;
    cnt = max(cnt, 1U);
    bbr->bw_probe_up_cnt = cnt;
}

// PROBE_UP phase 每一个 round 执行 inflight_hi 递增
/* In BBR_BW_PROBE_UP, not seeing high loss/ECN/queue, so raise inflight_hi. */
static void bbr_probe_inflight_hi_upward(struct sock *sk,
                                          const struct rate_sample *rs)
{
    /* For each bw_probe_up_cnt packets ACKed, increase inflight_hi by 1. */
    bbr->bw_probe_up_acks += rs->acked_sacked;
    if (bbr->bw_probe_up_acks >=  bbr->bw_probe_up_cnt) {
        delta = bbr->bw_probe_up_acks / bbr->bw_probe_up_cnt;
        bbr->bw_probe_up_acks -= delta * bbr->bw_probe_up_cnt;
        bbr->inflight_hi += delta;
        bbr->try_fast_path = 0;  /* Need to update cwnd */
    }
    if (bbr->round_start)
        bbr_raise_inflight_hi_slope(sk);
}

BBR_BW_PROBE_UP phase 中 inflight_hi 的递增有个细节：

• 在增量递增行为上，它按照慢启动的方式指数级逼近总容量，每 round 新增 probe 量翻倍。

inflight_hi 在一系列连续的 round 中递增量分别为 1，2，4，8，16，… 直到退出 BBR_BW_PROBE_UP phase，在 BBR_BW_PROBE_UP 期间 inflight_hi 会即时反馈到 tcp_snd_cwnd 本身，这意味着这种 Slow-Start 增量本身就是 cwnd 增量，这是一种高效的方法。
继续看 inflight_lo 之前，先看代码对 inflight_hi，inflight_lo 的注释，它规范了两个量的生命周期：

 * The model has both higher and lower bounds for the operating range:
 *   lo: bw_lo, inflight_lo: conservative short-term lower bound
 *   hi: bw_hi, inflight_hi: robust long-term upper bound
 * The bandwidth-probing time scale is (a) extended dynamically based on
 * estimated BDP to improve coexistence with Reno/CUBIC; (b) bounded by
 * an interactive wall-clock time-scale to be more scalable and responsive
 * than Reno and CUBIC.

long-term 的意思是，它不会在某个规律的 phase 中被重置，类似 Vegas 中的全局 minrtt，只会更新，不会重置。而 short-term 则只在一个 phase 内生效，会被周期性重置。

有了该认识，再看 inflight_lo 就简单了：

• inflight_lo 被初始化为 cwnd，遭遇 Loss or ECN Mark 之后，inflight_lo = (1 - beta) * inflight_lo。

这就是 BBRv2/v3 cwnd secondary control 的几乎全部，剩下的 pacing control 相比 BBRv1，PROBE_BW cycle 的定义有所改变，不再固定 round phase，做了细分：

• BBR_BW_PROBE_UP：不再固定目标 inflight = 1.25 * BDP，而是只要丢包率(ECN Mark 率)不过量，带宽 Probe 不吃力，就一直 Probe；
• BBR_BW_PROBE_DOWN：不再固定持续 1 个 round，而是 drain-to-target；
• BBR_BW_PROBE_CRUISE：不再固定持续 6 个 round，而是接近 2～3 Sec(后面解释)；
• BBR_BW_PROBE_REFILL：新增 phase，确保 inflight_lo，inflight_hi 可信。

BBR_BW_PROBE_UP 在 从 BBRv2 到 BBRv3 已经解释过，BBR_BW_PROBE_CRUISE 在 从 BBR 到 BBRv2 也有提到，这里重复一下。

如 BBRv2 draft 4.3.3.5.1 节所述，BBRv2 希望在 DC 和 Internet 都能和 Reno/CUBIC 友好共存，巧合的是，两类网络的典型 BDP 是一致的：

• DC 网络：40 Gbps / 8 bits-per-Byte * 20 us / (1514 Bytes) ~= 66 packets
• Internet：25Mbps / 8 bits-per-Byte * 30 ms / (1514 bytes) ~= 62 packets

意思是，为了让 AIMD 能充分发挥而不被 BBR 挤压，BBR_BW_PROBE_UP 之后大约 60 多个 RTT，BBRv2 便可友好地再次 BBR_BW_PROBE_UP，这个时间在 Internet 大约 2～3 secs(在 DCN 大约 1.3 ms)。该 Time Scale 不包含固定经验值，它是 rounds 的函数，自适应各类网络。这是一个事实上可靠的 BBR/Reno 共存保证。

所以在 BBRv2/v3 标准版，BBR_BW_PROBE_CRUISE 持续时间为：

/* Use BBR-native probe time scale starting at this many usec.
 * We aim to be fair with Reno/CUBIC up to an inter-loss time epoch of at least:
 *  BDP*RTT = 25Mbps * .030sec /(1514bytes) * 0.030sec = 1.9 secs
 */
static const u32 bbr_bw_probe_base_us = 2 * USEC_PER_SEC;  /* 2 secs */

/* Use BBR-native probes spread over this many usec: */
static const u32 bbr_bw_probe_rand_us = 1 * USEC_PER_SEC;  /* 1 secs */

至于 BBR.Swift，会有一篇单独的文章单独说。

最后看 BBR_BW_PROBE_REFILL。很多人对这个状态有疑问，它的意义是什么？还是看注释：

/* Send at estimated bw to fill the pipe, but not queue. We need this phase
 * before PROBE_UP, because as soon as we send faster than the available bw
 * we will start building a queue, and if the buffer is shallow we can cause
 * loss. If we do not fill the pipe before we cause this loss, our bw_hi and
 * inflight_hi estimates will underestimate.
 */
static void bbr_start_bw_probe_refill(struct sock *sk, u32 bw_probe_up_rounds)

注释从 inflight_hi 的视角写得很明白，我从 inflight_lo 的视角再解释一番。

BBRv2 引入 inflight_lo 来响应丢包，在 BBR_BW_PROBE_REFILL phase 之前 BBR_BW_PROBE_CRUISE phase 中任何丢包都会以 Multiplicative Decrease 拉低该值，它会直接影响 cwnd，进而影响 inflight，最终影响 bw。如果在 inflight_lo 已经被拉低后的状态直接开始 Probe，cwnd 可能已经处于一个低态，这会影响 Probe 的效果。如果不填满它本该填满的 Pipe，一旦一个不小心的丢包，吞吐就会被严重影响，不管承认不承认，BBRv2 开始，cwnd control 几乎已经成了 primary control。

因此，也正是在该 phase，在 BBR_BW_PROBE_UP 之前，short-term 的 inflight_lo，bw_lo 被重置，此后在不响应丢包的前提下用 max-bw filter 中的 maxbw 作为 pacing 持续 1 个 round 填满 Pipe，Pipe 满载，一切就绪后，进入下一轮 BBR_BW_PROBE_UP phase。

这里的 max-bw filter 值得一提。

在 BBRv1 中，该 filter 是一个 10-round window filter，而在 BBRv2 中发生了改变。 由于整个 PROBE_BW cycle 不再固定 round phase，完全取决于 phase 子状态机，因此 max-bw filter 就不能再用 minmax_running_max 记录，而采用一种更加简单的双数组结构来记录：

/* Incorporate a new bw sample into the current window of our max filter. */
static void bbr_take_max_bw_sample(struct sock *sk, u32 bw)
{
    bbr->bw_hi[1] = max(bw, bbr->bw_hi[1]);
}
/* Keep max of last 1-2 cycles. Each PROBE_BW cycle, flip filter window. */
static void bbr_advance_max_bw_filter(struct sock *sk)
{
    bbr->bw_hi[0] = bbr->bw_hi[1];
    bbr->bw_hi[1] = 0;
}

最后，也是最有意思的，BBRv2/v3 之所以 “性能比 BBRv1 差得多”，原因在于：

// v1：无条件取 max
static u32 bbr_bw(const struct sock *sk)
{
    return bbr_max_bw(sk);
}
// v2/v3：除了 Refill/ProbeUP phase，只要有 Loss 就取 low
static u32 bbr_bw(const struct sock *sk)
{
    return min(bbr_max_bw(sk), bbr->bw_lo);
}

cwnd 已倾向保守取 inflight_lo(只要 Loss/ECN-Mark，inflight_lo 就被砍)，pacing 亦取 bw_lo。

如果这是在 “劣化性能”，Google 那帮人难道都是傻子？如果这是在解决问题，如果这问题对你不是问题，你应该知道怎么改了吧。

浙江温州皮鞋湿，下雨进水不会胖。