概要(便于检索主题)：单流，多流收敛，probe buffer 挤压带宽，maxbw-filter wnd。
我曾经经常说 BBR 是个单流模型，而不是多流收敛模型，也做过不少评论，最近在复听 IETF 的大会，在 IETF100-ICCRG-20171113-1330(20:40’ 开始) 找到个正式说法，2017 年 ICCRG 大会，论文在这里：Experimental evaluation of BBR congestion control。
简单截个图，然后评论几句：
Works well if no congestion present 这句话非常讽刺。
关于 multiple flows 行为，见下图：
大 buffer 下，RTT 越大，侵占性越强，小 buffer 下，丢包。以下简单解释。
和 BBR 单流吞吐到顶即不变不同，多流大 buffer 场景，由于 B1/(B1 + B2) < (B1 + d)/(B1 + d + B2)，BBR probe up 时一定能挤占额外带宽，maxbw-filter 将记录一个偏大的 bw，而其它流并不主动降速，依然保持自身 maxbw-filter 的 bw，它们将共同在 buffer 排队，RTT 越大，inflight 越大，侵占性越强。而在多流小 buffer 场景，该行为可能将 BBR Opt point 推向 CUBIC 右边而造成高丢包。
No consistent fairness behavior 这句话点了题。
BBR is already in use: but probably application-limited 这句话扎心了。如果 BBR 全用于大文件传输，死命发送的那种应用，想必 BBR 应该用不起来。但也没必要专门用这个论据证明 BBR 不好，毕竟在未来 application-limited 应用会越来越多，死命发送的 capacity-seeking 应用才是少数，这个我也是不止一次评论过。
最后，BBR is still under development 这句话充满了希望。
对 BBR 的任何评价几乎都局限在它单流场景的优异表现，对 BBR 最优操作点的质疑似乎从来没有过。
BBR 的最优操作点早在 1970～1980 年代就为人所追求，BBR 死活不出炉的原因仅在于人们找不到，后来被证明永远找不到可以让多个流收敛到那个最佳操作点的理论支撑，直到 2010 年代，Google 做了大量实验，用实践和经验以及大量的数据表明(而不是证明)即使没有理论支撑，现实中对那个最佳操作点的收敛也足够好了，于是这个方法被放出来，就是 BBR 算法。
但 2017 年这次大会中给出的这个系列实验，不得不把 BBR 重新推回 Flow Control Power is Nondecentralizable 这篇论文以做重新评估。
但这个系列实现始终没有掀起足够的波澜促使 BBR 真正进化。
…
但 BBR2 直到 BBR3 的变化，除了叠加了作为补充性而非内置的 AIMD 以及微调了参数之外，并没有在 consistent fairness behavior 方面做结构性调整，很难让人相信 BBR3 已经是 multiple flows 收敛模型了。
“probe buffer 一定可以挤压出带宽” 和 “maxbw-filter wnd 过长” 两个因素一起让 BBR 操作点右移。“BBR 不认可 delivery rate 下降” 是自然结果，由此一定会造成 buffer 堆积。
BBR 有两类主动降速，分别是 loss-detect 后的守恒以及进入 probertt 状态，这两种主动降速前保持 maxbw 即可，非主动状态，被动监测到 bw 下降，要认，同时可以适当增加 probe up 频率，以 probe up 加速比随有效吞吐比例增加而下降做收敛。
这样收紧自身，自然就慢慢步入了多流场景了，总之，1 和 n，也是一个参数，要和其它参数联调，注意，是联调。
浙江温州皮鞋湿，下雨进水不会胖。
