让人们久等了的TCP BBR v2.0快要出炉了！（一）

这是连续的第四个雨夜了，这几天暴雨我几乎每晚都半通宵，晚上10点半左右睡觉，然后1点多就会醒来，听雨作文，无视并嘲笑着蚊子和飞机。

雨季来得晚了些，但却是猛的，我知道本周这可能是最后的雨夜了，所以我必须在这夜里写点东西或者做点事情，正好今天看到了bbr-dev list上的一篇topic，觉得有益，就想把它写下来，也就成了本文。

正文

2016年9月份，Google放出了其研究测试了好几年并且已经在其B4 SDN骨干网，油管全量部署的BBR拥塞控制算法，一时间得到了广泛关注。

有幸作为第一批研究BBR算法的那批人，我自己也做了很多分析和测试，并且和很大范围内的很多爱好者一起进行了各种讨论，此后不久，关于BBR的话题逐渐淡却，然而各大公司或者个人却都在私下里默默地对BBR进行进一步的调整或者说盲改，这个我就不多说了，挺烦的。

和大多数国内公司的盲改盲测不同，Google的做法显得有条有理，他们会首先在QUIC协议上就行试验性的实验并且经过充分的debug之后才会将确定性的结论实现在TCP协议上。这个意义上，QUIC BBR其实就是携带了充分调试信息的debug版本的BBR，实际上也是这样，毕竟30年前的TCP协议在传输反馈过程中信息量太少了，用它直接来做，显然不如出一个debug版本，而QUIC显然就是这个debug版本。就好像写程序一样，一开始的debug版本携带大量的信息将程序优化到极致，最后把debug信息去掉就是成型的发布版本了。

就在今年4月份，一位朋友发给我一份Google BBR最新的slides：
https://datatracker.ietf.org/meeting/101/materials/slides-101-iccrg-an-update-on-bbr-work-at-google-00
让我有了一些新的想法。该slides中提到了一个很重要的问题，那就是TCP BBR的失速问题，特别是在Wifi等无线的环境下，这个问题我之前也提到过。针对这个问题的解决，BBR给出了自己的思路。同时在该slides的最后，BBR做出了美好的展望。

这意味着BBR v2.0要来了？

然而终究还是没有来…然而有盼头了。

今年4月5日，也就是两个月前，BBR的作者之一Neal Cardwell在bbr-dev list上放出一个新的topic：
* RFC: Linux TCP BBR patches for higher wifi throughput and lower queuing delays *
大家可以follow一下下面的链接：
https://groups.google.com/forum/#!topic/bbr-dev/8pgyOyUavvY
就可以知道这是一个什么样的壮举。这个新的topic大概意思是在介绍一组最新的patch set。

写本文的目的是因为很多人是打不开上面的这些链接的，另外，就算能打开，估计也很多人不知道这个链接，所以我觉得我可以充当一个hub，我来写一篇文章帮大家介绍这里面的内容，或者说我更愿意当一个router，给大家指引一条到达的路径。

先看一下bbr-dev上的这个topic的主要内容，我在此摘录两段，这两段内容描述了这组patch set的主要内容：
先看第一段，主要介绍了BBR失速问题：

1: Higher throughput for wifi and other paths with aggregation

Aggregation effects are extremely common with wifi, cellular, and cable modem link technologies, ACK decimation in middleboxes, and LRO and GRO in receiving hosts. The aggregation can happen in either direction, data or ACKs, but in either case the aggregation effect is visible to the sender in the ACK stream.
 .
 Previously, BBR’s sending was often limited by cwnd under severe ACK aggregation/decimation because BBR sized the cwnd at 2*BDP. If packets were ACKed in bursts after long delays then BBR stopped sending after sending 2*BDP, leaving the bottleneck idle for potentially long periods. Note that loss-based congestion control does not have this issue because when facing aggregation it continues increasing cwnd after bursts of ACKs, growing cwnd until the buffer is full.
 .
 To achieve good throughput in the presence of aggregation effects, this new algorithm allows the BBR sender to put extra data in flight to keep the bottleneck utilized during silences in the ACK stream that it has evidence to suggest were caused by aggregation.

下面是第二段，这段主要是介绍BBR收敛慢的问题：

2: Lower queuing delays by frequently draining excess in-flight data
 .
 In BBR v1.0 the “drain” phase of the pacing gain cycle holds the pacing_gain to 0.75 for essentially 1*min_rtt (or less if inflight falls below the BDP).
 .
 This patch modifies the behavior of this “drain” phase to attempt to “drain to target”, adaptively holding this “drain” phase until inflight reaches the target level that matches the estimated BDP (bandwidth-delay product).
 .
 This can significantly reduce the amount of data queued at the bottleneck, and hence reduce queuing delay and packet loss, in cases where there are multiple flows sharing a bottleneck.

下面说一下我的理解。

这两个问题中，BBR收敛慢的问题我自己在2016年底就开始关注了，然而没有得到什么比较好的解法，一开始我只能按照下面的粗暴方式去解决：

    /* A pacing_gain < 1.0 tries to drain extra queue we added if bw
     * probing didn't find more bw. If inflight falls to match BDP then we
     * estimate queue is drained; persisting would underutilize the pipe.
     */
     return is_full_length && // 只是把||改成了&&以确保一次性强收敛。
    //return is_full_length ||
        inflight <= bbr_target_cwnd(sk, bw, BBR_UNIT);

这种找打的解法当然没能达到预期，虽然几位朋友测试说这样确实丢包减少了，但我个人认为那要match多少约束性场景，所以对测试结论持怀疑态度。我从来不相信这种拍脑袋的代码级的小修小改能对性能产生往好的方向的影响，即便是出自我自己之手我也会嗤之以鼻。可能我真的错了，并且错在了那个关键的时间点，我的那个修改(当然肯定还有别的修改，或变与只是其中之一)可能是正确的！

后来，我竟然放过了这段代码，依然保持了它原来的样子，但是即便不能在一次性drain到target，我也不希望后面走6个平稳的增益为1的cycle，我认为那太久了，于是我后来又有了一个优化，即把增益为1的平稳cycle从固定的6个改成2个10个之间的随机值，即：

static void bbr_advance_cycle_phase(struct sock *sk)
{    struct tcp_sock *tp = tcp_sk(sk);    struct bbr *bbr = inet_csk_ca(sk);

    bbr->cycle_idx = (bbr->cycle_idx + 1) & (CYCLE_LEN - 1);    if (bbr->cycle_idx == 2) {
        bbr->cycle_idx = 2 + next_pseudo_random32(jiffies)%11;
    }
    bbr->cycle_mstamp = tp->delivered_mstamp;
    bbr->pacing_gain = bbr_pacing_gain[bbr->cycle_idx];
}

嗯，这次效果还不错。之所以选择2到10而不是2到7，那是因为由于随机化，可能会让原本6个平稳周期缩短为0个，相当于减少了4个周期，那么就要有同样的概率让其多出4个平稳周期，而我，是相信概率的。就这样，我选择了6-4到6+4。

我不敢修改常数，我只能最多让数据在常数点达到平衡，我本来是想用正态分布的，但并不好实现…

在网络流量瞬息万变的场景下，保持固定心跳并不是什么明智的选择，1.25–0.75–1–1–1–1–1–1这种固定变速装置并不能正确应对环境的变化，这种经验来自平时自驾司机的观察，在国道或者高速上行驶，基本都是油门刹车随时踩的，BBR也应该这样，视情况选择是1.25还是0.75，或者1.

在对cycle进行了必要的随机化之后，我对BBR代码中的其它固定的常数都进行了随机化，概率分布化，以消除所谓的全局同步现象，也确实消除了，公平性也好了很多。

在这过程中，让我非常苦恼的是很难用数学方法去衡量BBR的表现。我们知道，以往的类似CUBIC，Vegas算法的paper中都会给出这个算法的数学模型，但是BBR很难找到这样的精确模型，它更多的是一种经验上的工程化算法，而不是一个基于数学模型的算法，所以说，它的曲线样子也就不固定咯。

我们知道Reno/CUBIC的曲线是锯齿，我问温州皮鞋厂老板BBR曲线是什么样子的，老板没有答上来，其实BBR v1.0的曲线跟人的心电图的样子非常像，就像一个固定时钟，这种固定的潮起潮落跟CUBIC没有本质的区别！所以一定要根据实际情况把曲线上的峰谷打散掉。

我们看一下今天展示的这个BBR v1.5的patch set是怎么解决这个问题的，首先它废掉了固定的cycle推进模式：

static void bbr_advance_cycle_phase(struct sock *sk)
{    struct tcp_sock *tp = tcp_sk(sk);    struct bbr *bbr = inet_csk_ca(sk);    if (bbr_drain_to_target) {        // 打散后的cycle推进逻辑在这里！
        bbr_drain_to_target_cycling(sk, rs);        return;
    }    // 固定的cycle推进逻辑终将成为历史
    bbr->cycle_idx = (bbr->cycle_idx + 1) & (CYCLE_LEN - 1);
    bbr->cycle_mstamp = tp->delivered_mstamp;
    bbr->pacing_gain = bbr_pacing_gain[bbr->cycle_idx];
}

接着让我们看一下冰山下面有什么。是的，好奇让人前行(嫉妒让人潜行?)：

static void bbr_drain_to_target_cycling(struct sock *sk,                                        const struct rate_sample *rs)
{    struct tcp_sock *tp = tcp_sk(sk);    struct bbr *bbr = inet_csk_ca(sk);    // elapsed_us表示从本轮开始到现在的时间。
    u32 elapsed_us =
            tcp_stamp_us_delta(tp->delivered_mstamp, bbr->cycle_mstamp);
    u32 inflight, bw;    if (bbr->mode != BBR_PROBE_BW)        return;    /* Always need to probe for bw before we forget good bw estimate. */
    // 如果超过了一轮的时间，就要开启新的一轮。
    // 注意：每一轮的周期数被随机了，周期数不再固定为8，而是2到8之间的随机值！
    // 我之前怎么就没有想到全局随机呢？？？
    if (elapsed_us > bbr->cycle_len * bbr->min_rtt_us) {        /* Start a new PROBE_BW probing cycle of [2 to 8] x min_rtt. */
        bbr->cycle_mstamp = tp->delivered_mstamp;
        bbr->cycle_len = CYCLE_LEN - prandom_u32_max(bbr_cycle_rand);        // 每一轮均从ProbeMore周期开始！
        bbr_set_cycle_idx(sk, BBR_BW_PROBE_UP);  /* probe bandwidth */
        return;
    }    /* The pacing_gain of 1.0 paces at the estimated bw to try to fully
     * use the pipe without increasing the queue.
     */
     // 每一轮均从ProbeMore周期开始，那么平稳的cruise周期肯定是
     // 从Drain周期下来的，如果进入了平稳的cruise周期，便不再变化，
     // 直到结束，仔细想想，这个和我的那个cycle随机化修改是完全一
     // 致的啊！！
    if (bbr->pacing_gain == BBR_UNIT)        return;
    inflight = rs->prior_in_flight;  /* what was in-flight before ACK? */
    bw = bbr_max_bw(sk);    /* A pacing_gain < 1.0 tries to drain extra queue we added if bw
     * probing didn't find more bw. If inflight falls to match BDP then we
     * estimate queue is drained; persisting would underutilize the pipe.
     */
     // 如果处在Drain周期，那么就一直Drain到inflight等于target为止！
    if (bbr->pacing_gain < BBR_UNIT) {        if (inflight <= bbr_inflight(sk, bw, BBR_UNIT))            // Drain成功后便进入到了平稳的cruise周期。
            bbr_set_cycle_idx(sk, BBR_BW_PROBE_CRUISE); /* cruise */
        return;
    }    /* A pacing_gain > 1.0 probes for bw by trying to raise inflight to at
     * least pacing_gain*BDP; this may take more than min_rtt if min_rtt is
     * small (e.g. on a LAN). We do not persist if packets are lost, since
     * a path with small buffers may not hold that much. Similarly we exit
     * if we were prevented by app/recv-win from reaching the target.
     */
     // 每一轮从ProbeMore开始，只有在出现丢包，RTT增加等情况下会进入Drain周期。
     // 注意：elapsed_us是从本轮开始计数，到当前的时间除以RTT正好记录了
     // 经过了多少个RTT，退出ProbeMore的条件是，至少经过了一个RTT，
     // 这一点和BBR 1.0版本完全一致。
    if (elapsed_us > bbr->min_rtt_us &&
            (inflight >= bbr_inflight(sk, bw, bbr->pacing_gain) ||
            rs->losses ||         /* perhaps pacing_gain*BDP won't fit */
            rs->is_app_limited || /* previously app-limited */
            !tcp_send_head(sk) || /* currently app/rwin-limited */
            !tcp_snd_wnd_test(tp, tcp_send_head(sk), tp->mss_cache))) {
            bbr_set_cycle_idx(sk, BBR_BW_PROBE_DOWN);  /* drain queue */
            return;
    }
}

这个patch证明我之前的思路还是对的，从那个“||”改为“&&”的时候就是正确的，此后加上我那个随机化平稳cruise周期基本就是这个代码了。这里可以说“||”改为“&&”是一个代码上的小trick，而我觉得真正有意义的地方在于随机化cycle后并且一次性Drain to target 。

好了，关于BBR收敛慢的问题暂时说到这里，相信BBR的这个patch也只是解决这个问题的一个开始，我们都很希望去面临一个开始，而不是结束，不管再好的结束，都不如一个跌跌撞撞懵懂的开始。

让我们继续本patch的下一个主题，即BBR失速问题。

关于这个问题，我自己也有一个解法：
TCP BBR失速控制的一个小trick一个小patch：https://blog.csdn.net/dog250/article/details/80203520
当时已经看过了https://datatracker.ietf.org/meeting/101/materials/slides-101-iccrg-an-update-on-bbr-work-at-google-00这个slides，然而并没有看到今天这个patch set的代码，所以我写了一个完全不一样的，不使用windowed max，而是使用了移动指数平均的方法。我的那个实现其实是有问题的，问题在于我的计算周期太短了，我是每次ACK到达都会去计算速率，这样做是不是有失精度呢？

见贤思齐，我还是更推崇Google的做法。这并非我自己的不自信，在这个点上我是确实不力。对于上面那个解决收敛慢的方法，如今，我还是比较自信的。

今天，我就简单说一下Google使用windowed max的方式来记录extra AKCed，从而计算extra cwnd的方法。

任何教唆都不如直接上代码，先看bbr_set_cwnd：

static void bbr_set_cwnd(struct sock *sk, const struct rate_sample *rs,
             u32 acked, u32 bw, int gain)
{
    ...
    target_cwnd = bbr_bdp(sk, bw, gain);    /* Increment the cwnd to account for excess ACKed data that seems
     * due to aggregation (of data and/or ACKs) visible in the ACK stream.
     */
    // 这个才是我们关注的！为cwnd增加了extra cwnd
    target_cwnd += bbr_ack_aggregation_cwnd(sk);
    ...
}

循着这个bbr_ack_aggregation_cwnd，看个究竟：

static u32 bbr_ack_aggregation_cwnd(struct sock *sk)
{
    u32 max_aggr_cwnd, aggr_cwnd = 0;    if (bbr_extra_acked_gain && bbr_full_bw_reached(sk)) {        // 计算一个上界
        max_aggr_cwnd = ((u64)bbr_bw(sk) * bbr_extra_acked_max_us)
            / BW_UNIT;        // 这句中的bbr_extra_acked最重要，至于又一个gain，权当经验值好了！
        aggr_cwnd = (bbr_extra_acked_gain * bbr_extra_acked(sk))
            >> BBR_SCALE;
        aggr_cwnd = min(aggr_cwnd, max_aggr_cwnd);
    }    return aggr_cwnd;
}

我说这虽然可能是BBR 2.0里面的自带功能，但却是一个十足的无失速BBR版本的1.0，这也是一个开始，解决失速问题的开始，不要苛求精确。

我们接着看bbr_extra_acked里面到底怎么取到的值：

/* Return maximum extra acked in past k-2k round trips,
 * where k = bbr_extra_acked_win_rtts.
 */static u16 bbr_extra_acked(const struct sock *sk)
{    struct bbr *bbr = inet_csk_ca(sk);    return max(bbr->extra_acked[0], bbr->extra_acked[1]);
}

到这里，我们应该能看明白这其实是取了之前两轮中的最大值，至于什么是一轮，其实就是10个RTT，这里巧妙的使用了倒换数组，也就是new，old两个容器互相交叉使用，new满了倾倒内容后成为old，然后old成为new，这种用法在O(1)调度器和RCU锁的实现中都有用到，也是一个常用的技巧。

接下来看一个最后的函数，即如何来计算extra ACKed的值，其实，只看注释应该就够了，但是那和直接看那个slides无异。为了展示实现上的技巧，还是要贴出代码最实在：

/* Estimates the windowed max degree of ack aggregation.
 * This is used to provision extra in-flight data to keep sending during
 * inter-ACK silences.
 *
 * Degree of ack aggregation is estimated as extra data acked beyond expected.
 *
 * max_extra_acked = "maximum recent excess data ACKed beyond max_bw * interval"
 * cwnd += max_extra_acked
 *
 * Max extra_acked is clamped by cwnd and bw * bbr_extra_acked_max_us (100 ms).
 * Max filter is an approximate sliding window of 10-20 (packet timed) round
 * trips.
 */
 static void bbr_update_ack_aggregation(struct sock *sk,                                        const struct rate_sample *rs)
 {
    u32 epoch_us, expected_acked, extra_acked;    struct bbr *bbr = inet_csk_ca(sk);    struct tcp_sock *tp = tcp_sk(sk);    if (!bbr_extra_acked_gain || rs->acked_sacked <= 0 ||
        rs->delivered < 0 || rs->interval_us <= 0)        return;    if (bbr->round_start) {
        bbr->extra_acked_win_rtts = min(0x1F,
                                        bbr->extra_acked_win_rtts + 1);        // 每10个rtt作为一轮参与计算。
        if (bbr->extra_acked_win_rtts >= bbr_extra_acked_win_rtts) {
            bbr->extra_acked_win_rtts = 0;            // 交错使用extra_acked倒换数组容器
            bbr->extra_acked_win_idx = bbr->extra_acked_win_idx ?0 : 1;
            bbr->extra_acked[bbr->extra_acked_win_idx] = 0;
        }   
    }    /* Compute how many packets we expected to be delivered over epoch. */
    // epoch_us表示自从收到“比预期过量的ACK”开始到现在的时间间隔！
    epoch_us = tcp_stamp_us_delta(tp->delivered_mstamp,
                                    bbr->ack_epoch_mstamp);    // 很显然的预期公式，bw*t = acked。
    expected_acked = ((u64)bbr_bw(sk) * epoch_us) / BW_UNIT;    /* Reset the aggregation epoch if ACK rate is below expected rate or
     * significantly large no. of ack received since epoch (potentially
     * quite old epoch).
     */
    // 只有从开始收到比预期多的ACK，SACK时才开始计时。另外，太多也不行。
    if (bbr->ack_epoch_acked <= expected_acked ||
        (bbr->ack_epoch_acked + rs->acked_sacked >=
        bbr_ack_epoch_acked_reset_thresh)) {
        bbr->ack_epoch_acked = 0;
        bbr->ack_epoch_mstamp = tp->delivered_mstamp;
        expected_acked = 0;
    }    /* Compute excess data delivered, beyond what was expected. */
    bbr->ack_epoch_acked = min(0xFFFFFU,
                                bbr->ack_epoch_acked + rs->acked_sacked);    // 用实际的ACK，SACK数量减去预期的，就是extra。
    extra_acked = bbr->ack_epoch_acked - expected_acked;
    extra_acked = min(extra_acked, tp->snd_cwnd);    // 加入到容器以供set cwnd逻辑来取值。
    if (extra_acked > bbr->extra_acked[bbr->extra_acked_win_idx])
        bbr->extra_acked[bbr->extra_acked_win_idx] = extra_acked;
}

这个逻辑其实想想，理解上也并不困难，关键就是要去实现它，并且正确地实现它。

很多时候，思路虽然重要，但正确的实现思路更加重要，因为这会影响到我们的认知。思路是一种解决问题的想法，它十有八九是正确的，请相信我，它真的十有八九是正确的。除非有人故意使坏，解决问题的心大家都是一致向前的，差别在于前进的远和近，问题理解了，那么解决问题的方法还会没有吗？

在实现并实施了一系列的方法后，为什么没有达到预期？很多时候可能就是你实现的方法不对而不是思路不对。这个时候人的素质就分出差别了。强大的人首先会审查实现在保证实现万无一失后再去审视思路，而一般的乌合大众则直接攻击思路，这显然是无益于任何事情向前推进的。

大隐隐于微信群，小隐隐于会议室。没有任何的实现前，多做事，少扯淡，推理谁都会，A的不见得比C的更高明。

Google的开源项目基本都是公开公共的邮件group交流，其实任何成功的项目都是如此，在没有实现之前，任何方案都是有待商榷。

原文出处