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网络拥塞可称作争抢拥塞。
具体看下两种拥塞的不同:
关于争抢拥塞和排队拥塞的关系,请参考:
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算法中,测量带宽表现为 d e l i v e r e d i n t e r v a l \dfrac{delivered}{interval} intervaldelivered,而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网络里的终端:
现在谈谈丢包,其实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了:
上面这一系列测试,只在确认Wi-Fi所造成的RTT抖动的剧烈程度,依托这些数据来看,BBR很多操作的结论便无法成立。
结果是,BBR在有线可控的网络中确实是以正交测量BltBW和RTprop来获得高带宽利用率从而轻松击败CUBIC,然而在Wi-Fi网络,似乎只能依靠大力出奇迹来取胜,但也并非每次都能成功,很多时候也会输得很惨,经常会有人说,怎么BBR还没有CUBIC好,Wi-Fi可能就是原因。
Wi-Fi自始至终就没有宣称过自己是为性能而生,Wi-Fi只是一个近场通信的媒介。想想看同轴时期的以太网,是不是和如今的Wi-Fi一样,再看看现在的以太网,我们期待Wi-Fi在未来某一天,开始追求性能。
更多Wi-Fi性能分析的文章,参考:
http://www.h3c.com/cn/d_201109/724573_97665_0.htm
http://www.h3c.com/cn/d_201006/677615_97665_0.htm
至于LTE算不算弱网,我对此了解不多,不多分析。
我周二的时候发了一则朋友圈吐槽:
WiFi为啥就是不实现真正全双工,非要两个方向共享介质,信道仲裁。这对TCP这种feedback协议很不友好啊,而且对quic也不友好。
答案可能很简单,就是Wi-Fi简单成本低,无论在信道质量,通信距离,系统负载能力,功耗上,Wi-Fi和LTE并非瞄准同一个目标而设计的,如果把Wi-Fi修成LTE了,那它还是Wi-Fi吗?了解下WiMax?
浙江温州皮鞋湿,下雨进水不会胖。