当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算法中,测量带宽表现为 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局部:
当BBR遇到Wi-Fi弱网会怎样_第1张图片

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

一个合理但不唯一的解释就是,接收端是一个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百人接入时测试结果:
    当BBR遇到Wi-Fi弱网会怎样_第2张图片
    抖动很厉害,看均差即可。
  • 公司Wi-Fi百人接入时AP下一跳路由器上测试结果:
    当BBR遇到Wi-Fi弱网会怎样_第3张图片
    与千百人的Wi-Fi同一条路径,就隔了一个Wi-Fi网络的子路径,相当稳定。

上面这一系列测试,只在确认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?


浙江温州皮鞋湿,下雨进水不会胖。

你可能感兴趣的:(BBR,TCP,拥塞控制)