当BBR遇到Wi-Fi弱网会怎样

Wi-Fi是名副其实的弱网，BBR在Wi-Fi环境的表现不尽人意。临此囧，第一个想到的就是如何去优化，当尝试了很多优化都没有好的效果时，不优化反而是最优的。

最好的全局优化就是不优化，现实中80%+的场景都是不需要优化的，为了不到20%的场景进行全局优化得不偿失，问题的关键不是如何全局优化，而是识别出那不到20%的部分。

Wi-Fi其弱体现在RTT抖动和高丢包率两方面，接入终端越多就越弱。而包括BBR在内的绝大多数拥塞控制算法均以RTT和丢包作为依据来运作，因此在Wi-Fi这些拥塞控制算法很难正确发挥作用。

思考了一断时间弱网传输优化，写一点想法。

Wi-Fi是一种共享介质半双工网络，当AP和多个接入终端同时发送或接收时，只有一个可以成功，这是CSMA/CA的标准规定的。接入多个终端的Wi-Fi网络，显然处在拥塞状态，但该拥塞与有线网络的排队拥塞不同。CSMA/CA靠争抢获得信道，因此Wi-Fi网络拥塞可称作争抢拥塞。

具体看下两种拥塞的不同：

排队拥塞：队列在路由器中有序形成，拥塞体现在RTT的增加，队列拥塞缓解体现在RTT的减少。以RTT的一阶导数识别排队拥塞。
争抢拥塞：无队列，完全依靠无序争抢和退避。拥塞体现在RTT均差变大，拥塞缓解体现在RTT均差变小。以RTT均差的一阶导数识别争抢拥塞。

关于争抢拥塞和排队拥塞的关系，请参考：
https://blog.csdn.net/dog250/article/details/90340322
https://blog.csdn.net/dog250/article/details/90446782

Wi-Fi的争抢拥塞特征与路由器排队拥塞特征的区别直接影响了BBR的两个核心行为。

首先看对BltBW测量的影响。

在有线全双工网络中，由于队列是在带宽打满后有序生成的，因此一条流的测量带宽是单调增加的，一直到开始排队，带宽不再增加，这种有序并可预测的测量结果可以直接对带宽进行正确的预估。

然而在Wi-Fi环境，这个结论将不再成立。当大量终端接入同一个Wi-Fi时，每一个终端发送报文的争抢时延是随机的，这是导致RTT抖动的核心原因之一，RTT的抖动导致测量带宽的抖动。但BBR采用10 rounds的max-filter来维持BltBW，这将对带宽的预估造成误判。如果是好运气导致数据包快速发出而获得很高的测量带宽，以此乘以gain获得的预估带宽可能会偏大，导致更大概率的冲突。

在BBR算法中，测量带宽表现为 $\dfrac{delivered}{interval}$ ，而interval忽高忽低，且受到同连接ACK流冲突的影响(这个后面说)，而BBR假设在达到BltBW前RTT是不变的，至少其均差要控制在一个很小的范围内。BBR的Reach-full逻辑会因此受到影响，在好运气带来的大测量带宽之后，连续3次的坏运气在多终端接入的Wi-Fi场景是大概率事件，这会导致BBR提前认为已经达到了BltBW，从而降低了带宽利用率。

再看对RTprop测量的影响。在Wi-Fi环境，由于RTT的随机抖动，即便是进入ProbeRTT状态保持4个inflight排空了队列，也不一定能测得RTprop，因为并未解除Wi-Fi网络的争抢。PRTprop是在随机的任意时刻均可测得的，这会破坏同步ProbeRTT的公平收敛机制。

BBRv2可能更适合Wi-Fi的场景，在ProbeRTT状态仅仅对发包数量乘性减，而不是降到4个，这便可以降低冲突而减缓抖动(虽然BBRv2的这个设计初衷并非如此)。

这就是我们所看到的，BBR在Wi-Fi环境无法遵循BltBW和RTprop正交测量的原则。但无论如何，依靠大力出奇迹，BBR依然可以吊打CUBIC。

争抢式CSMA/CA十分直接地体现了统计复用，目前的BBR算法无法在数学上定义这种统计复用，这也就是为什么那些基于理想马尔可夫链，泊松到达等排队论理论的魔改版BBR一离开实验室效果都不好的原因。

BBR在Wi-Fi网络还有一个有意思的场景，那就是数据报文和ACK报文的冲突与互斥。

当一个BBR流源源不断从AP运输数据到无线终端时，该连接的ACK流正从反方向流向AP，由于共享介质，要么数据通过，要么ACK通过，这势必会导致冲突，且数据流pacing越大，ACK流pacing就会越大，冲突概率越大，这形成了一个尴尬的反馈环，阻止数据流pacing进一步增加。

解决这个问题最直接的方法就是减少ACK报文的数量。

在Wi-Fi的标准中，考虑到聚合连续的小包有利于减少冲突，IEEE802.11定义了帧聚合特性，可以把多个小包聚合到一个Wi-Fi帧：
https://inet.omnetpp.org/docs/showcases/wireless/aggregation/doc/index.html
除此之外，TCP层面也可以修改接收端以减少ACK的数量：
https://cs.stanford.edu/~keithw/tack-sigcomm2020.pdf
但这些机制都不尽人意，解决一个问题的同时，引入了更多别的问题，然后引出更多解决这些问题的更多方案，越来越复杂，却依然逃不出实验室。这本质上是TCP自带feedback时钟的本质特征和Wi-Fi的共享介质本质特征共同决定的，几乎无解。

最后一个问题有点出乎意料。和pacing发送会缓解排队拥塞相反，burst发送会缓解争抢拥塞。

在CSMA/CA约束下，统计意义上所有终端在冲突中的机会是均等的，因此，空闲时隙总是稀疏分布的，如果一个终端抢到了一个空闲时隙，那么下一个时隙依然空闲的概率很大。用burst方式发送数据可以天然利用附近空闲的时隙，而不是重新进行仲裁。

关于Wi-Fi场景下burst发送的话题，可以参考下面的论文：
https://upcommons.upc.edu/bitstream/handle/2117/172208/main.pdf

来看一个具体场景，这是一个优化版BBR发送端的tcptrace局部：
在这里插入图片描述

猜猜看接收端发生了什么？

一个合理但不唯一的解释就是，接收端是一个Wi-Fi网络里的终端：

区域1：终端正常接收数据并回复ACK。
区域2：终端路过一个信号死角，大概有几百毫秒的静默，什么都没有发生，箭头所示之处有几次激进重传“优化”。
区域3：信号恢复，一开始RTT很大，逐渐减小，这意味着AP上buffer逐渐排空，前期收到的DSACK说明那几次重传是没有必要的，只是客户端失联暂存数据在AP了，恢复之后，数据包从AP往外持续burst，导致后期丢包增加。
区域4：开始补包重传，发送端采集到了很高的丢包率，但有效带宽却没有增加。
区域5：激活了BBR LT逻辑，无论怎样，速度也就那样了，这大概率是一次由于激进重传导致的误判。

现在谈谈丢包，其实Wi-Fi很容易因为信号衰减和干扰造成丢包，这种丢包不是排队拥塞导致的，它对类似CUBIC的影响极大，但对于BBR，由于它天然抗随机丢包，看上去影响并不大，但实际上并非如此。

时延的抖动会导致发送端在计算sRTT，RTO，RACK窗口时存在一定的波动性，天然依靠RACK的BBR在随机丢包后可能会基于RACK的时间窗口激进标记lost，这会造成重传率的增加，显然这导致本已遍地冲突的Wi-Fi网络雪上加霜。另一方面，正如上面的示例，过多的标记lost可能会让连接误入LT，影响带宽利用率。

结论是什么？

结论就是，当检测到存在Wi-Fi环境时，不要做任何优化，切换到原生BBR，相信Google的大佬们做的比你优秀，不要试图在终端路过信号死角的时候激进发送，这会激起连锁反应。“什么都不做”很难做到不是吗？毕竟当检测到那么久的静默时，任何人总希望做点什么，比如发送一个数据包。

我这里倒是有一个优化截止点，在sRTT不超过MinRTT的2倍前提下，最后一个包发送完启动tlp timeout的timer，到期后重传UNA，后面跟一个1字节探测，如果再过一个tlp timeout没有任何回应，就恢复到原生的算法。背后的逻辑是，如果网络很好，便不会如此静默，如果真的静默，激进发送很容易导致buffer溢出，进而导致一系列尴尬的连锁反应。

下面是我在手机上测试Wi-Fi与5G网络ping同一个intel地址23.33.80.29所获得的RTT，肉眼就可以看出抖动，就不用mtr了：

5G静止状态的ping结果：

感觉还算稳定。
5G进入上海西中环的一个地下隧道的结果：

已经抖得没法看了，且伴随丢包。这可以理解为地下隧道的信号弱导致。
5G时速60公里时的结果：

和静止时差不多，至少在60公里时速以内，5G还算稳定。
家庭Wi-Fi单人接入时的结果：

非常稳定，几乎就和家庭有线网络一样，稍微差一点，但不多。
两人接入家庭Wi-Fi，老婆在刷剧，AP和接入位置隔承重墙：

冲突导致了RTT抖动，只能这么理解，另外，有朋友说我的AP该换了，不过这不是我买的，这是电信送的。
早高峰地铁行驶中的5G测试结果：

和在高架桥时速60公里结果差不多，稳当。
早高峰地铁进站停站5G测试结果：

没法看了，站台上接入终端太多，移动性大，可能会造成影响，对4G/5G不了解，不分析。
公司Wi-Fi百人接入时测试结果：

抖动很厉害，看均差即可。
公司Wi-Fi百人接入时AP下一跳路由器上测试结果：

与千百人的Wi-Fi同一条路径，就隔了一个Wi-Fi网络的子路径，相当稳定。