盯着 BBR 带宽吊打 CUBIC 时，要看它为此能力而付出的代价。

BBR 在轻微丢包( < 1% )场景重传率比 CUBIC 高 6～10 倍，稍重到重丢包场景可超过 20 倍甚至上百倍，这种代价足以让以带宽计费者重新斟酌。

经过若干交换机(而非路由器)的二层直连环境，简单 iperf 打流 100ms，分别灌参数 -Z bbr/cubic，常态跑以下命令：

 while true; do ss -ti|grep -A1 "10.198.100.16:12345"; done

观察 p = $bytes_retrans / $bytes_sent，BBR 比 CUBIC 高。

无论 BBR or CUBIC，哪里发生了丢包？我观察协议栈计数，并使 ethtool 探测网卡层丢包计数，未见增加，那一定是交换机丢包。事实上果然是。

题外话，我强烈需要具有反压能力的交换机支持一种名字类似 traceswitch 或 mts 的命令。

当我加入 fq：

tc qdisc add dev eth0 root fq

再跑测试，CUBIC 的 p 值更小了，甚至为 0，而 BBR 未有大不同。意料之中，BBR 自 4.14 后即使用 Internal pacing timer，至于 fq 不 fq 早就无关紧要。

BBR 高重率传到底来自哪里？

如果 BBR 自身的行为没有造成更多丢包而重传，就是误判。然而丢包标记算法无关，无论 scoreboard 还是 RACK，BBR 和 CUBIC 使用同一套。so，重传一定来自自身的行为。

BBR 自身哪些行为可能导致丢包？答案是 ProbeBW 状态的 25% up probe。

cwnd 约束至 2*BDP，BBR 允许在一个 round 内 probe 到 5/2 倍的 BDP，即使在标准流场景，对浅 Buffer，已足以造成丢包，而且丢包还不少。就更别提混部场景的变幻莫测了，瞬时的高带宽假象会被记住，以此假象 yy 10 个 rounds 而不可自拔，自然司命之所属，无奈何也。

我常以为，要做好两点，其一不要记住瞬时高带宽假象，其二 up probe 后若丢包一定要 MD(multiplicative-decrease) pacing rate，可以判断，第一点很难，而第二点容易，BBRv2 is on its way。

可定论，说到底 BBR 本质上是一个 MIMD(multiplicative-increase/multiplicative-decrease) 争抢算法，别的 feature 都是幌子。

这种算法在 2016 年底 BBR 发布之前很常见，包括我在内不知多少人于实验室带宽吊打 CUBIC 而狂喜，BBR 实际只为这类算法增加些公平性修正，比如 probe 之后的 drain，比如 ProbeRTT。

真相是，即使在实验室，把高丢包高重传代价计入，只算有效传输效率，BBR 并不比 CUBIC 更佳。

BBRv2 引入了丢包信号，这是理性的回归。忽略丢包影响即使在真拥塞场景也并不可靠，BBRv1 轮毂大，可轻而易举越过噪声丢包，但 MI 导致的新丢包却也越过去了，然后就刚兑。BBR 本是来解决 Bufferbloat 的，刚兑却加剧了 Bufferbloat，有趣。

再一真相，把引发高重传的 BBRv1 feature 逐个剥离，剩下的就是 CUBIC，最终又回到了原点，BBRv2 在这条路中间找了个位置。

怪不得 BBR paper 把范雅各布森(Van Jacobson)的大名赫然印上，不只是尊敬，他本身就是作者。

BBR 的 BltBW-RTprop 模型是里程碑，但现实中的 BBR 算法看起来并不是。

BBR 高重传率到底发生在哪儿？掰扯完了，最终是个循环，并不高尚。但这也是个开始。