TCP 拥塞避免算法( 八 ) _算法

文章插图

来自[4]
BBR 跟 CUBIC 等基于丢包的算法共存时会有问题吗？列一下 Reno ， CUBIC ， BBR 三个在时间和发送速率上的图做对比。

文章插图

来自[1]
之前提到 TCP Vegas ， Vegas 会被基于丢包的算法挤掉份额，不能跟这些算法共存，所以无法流行起来。对于 BBR 的话，它抢占份额的方式主要靠 ProbeBW 期间按 1.25 倍估计值发送数据，会给链路带去压力，为自己抢占生存空间；再有就是 Startup 阶段， BBR 相对 CUBIC 来说会为链路带去更多数据去抢占份额，这个只在初始阶段有用，但如果 BBR 上的数据如果能持续发送，初始期占的份额可能就能一直保持下去。
对 BBR 和基于丢包的 Congestion Avoidance 的分析有两种不同的结果：

BBR 在 ProbeBW 阶段虽然会将发送速度提高到 1.25 倍但毕竟持续时间短，一半以上的时间还是以估计速率在发数据。如果不能给链路带去足够压力， BBR 会被其它基于丢包的算法挤掉，因为 BBR 会认为延迟升高了，需要降低自己的发送速度，这么逐步降低；
BBR 可能错误的估计链路延迟，比如估算链路是否有排队主要通过 RTT 有没增加完成，但 RTT 即使不增加可能链路也有排队，比如链路上队列处在基本满的状态， BBR 认为此时的 RTT 就是链路 RTT 最小值，于是保持速度发数据，它还容忍丢包，但基于丢包的算法在此时就会降速。

据说 google 给出来说 BBR 可以很好的跟 CUBIC 等算法共存，但参考 [1] 的Sharing 一节在两种场景测试发现 BBR 比 CUBIC 占用更多资源或者说份额。
BBR 如何处理丢包在网上搜很多文章都说 BBR 根本不管丢包，完全基于自己的周期即 ProbeBW 内的周期去计算发送率， CWND 来发数据包，所以 BBR 根本无视丢包。但实际上 BBR 作者写的 BBR 介绍里明确说了 BBR 是会管丢包情况的，来自 BBR: Congestion-Based Congestion Control - ACM Queue ：

The network path and traffic traveling over it can make sudden dramatic changes. To adapt to these smoothly and robustly, and reduce packet losses in such cases, BBR uses a number of strategies to implement the core model. First, BBR treats cwnd_gain×BDP as a target that the current cwnd approaches cautiously from below, increasing cwnd by no more than the amount of data acknowledged at any time. Second, upon a retransmission timeout, meaning the sender thinks all in-flight packets are lost, BBR conservatively reduces cwnd to one packet and sends a single packet (just like loss-based congestion-control algorithms such as CUBIC). Finally, when the sender detects packet loss but there are still packets in flight, on the first round of the loss-repair process BBR temporarily reduces the sending rate to match the current delivery rate; on second and later rounds of loss repair it ensures the sending rate never exceeds twice the current delivery rate. This significantly reduces transient losses when BBR encounters policers or competes with other flows on a BDP-scale buffer.

更长的在这里： Modulating cwnd in Loss Recovery
细节很多，我看的很晕。在看 BBR 处理丢包策略前，至少得先回忆一下 TCP 的丢包处理机制，一个是 Retransmission Timeout (RTO) ，一个是 Fast Retransmission ，这两个概念就不记录了，可以翻一下 Wiki 。大致上是说如果遇到重传 RTO ，发送者会认为所有 Inflights 数据都丢了， CWND 会降为 1 MSS ，行为和 CUBIC 类似。在之后持续收到 ACK 的话，会逐步增加 CWND 值。每次 ACK 时候一方面会更新各种统计值，再有会更新 CWND 值， CWND 的增幅就是每次收到 ACK 时候 ACK 的数据量。每个 ACK 都会尝试去更新，直到 CWND 达到 target_cwnd 即当前估计的 BDP 和 cwnd_gain 的乘积。
如果是 Fast Retransmission ，发送者则认为链路遇到丢包但仍然存在有效 Inflights 数据。这时首先将 CWND 降低到当前与当前 deliveryRate 相匹配的值，之后一段时间发送速率不能超过 deliveryRate 的两倍。直到退出 Fast Retransmission 阶段后， CWND 恢复为丢包出现前记录的 CWND 值。就是说在 RTO 或 Fast Retransmission 前会记录当时 CWND ，在出 Fast Retransmission 或 RTO 后恢复到记录的 CWND 。