信 bbr 的伙计们,我又要泼冷水了,哈哈。
从先 bbr 的海报开始,相信大家也是被它唬住的:
注意横坐标标度是对数,这就凸显了优势。
把它展开到自然数坐标,再把其它对照画在一个坐标系里,在此之前,须知的前置知识是 aimd 算法的吞吐与丢包率的关系(正好是上图的红线):
T
=
α
1
R
T
T
1
p
T=\alpha\dfrac{1}{RTT}\sqrt{\dfrac{1}{p}}
T=αRTT1p1
重画上图如下图所示:
可见,bbr 只是 pixie 的变体,而 cycle_len = 2 也只是柔和版的 pixie:如果将 cycle_len 和 filter_win 缩小到 2,bbr 就是一个每次以 5/4 增益发包的 pixie 算法,如果 cycle_len 恢复为 8,它就是每 8 周期以 5/4 增益发包,期间保持 maxbw 的 pixie 算法,cycle_len 越大,对 rtt 变化越迟钝。
丝毫看不出 bbr 有 “拥塞控制” 含义。过了这么多年,那张抗 20% 丢包的海报不值得推荐。无论抗随机丢包,还是抗拥塞丢包,都是保带宽,只会加剧拥塞。详情参见:bbr 真的抗丢包吗。
拥塞多由突发导致,多数转瞬即逝,至少不恒久持续,拥塞发生时的高响应度很重要,但 bbr 对时延不敏感,做不到高响应度。
分析 pixie(记住 bbr 只是柔和版 pixie) 算法,pacing_rate = deliver_rate / (1 - p) 旨在用超量发送弥补丢包损耗,只为保带宽,但多发出的包依丢包率 p 是要丢掉的,此发送能耗为保带宽而浪费了,在丢包点上游,多余流量反而加剧拥塞,此举从头到尾接近无用功甚至净损耗。
现在来看 aimd(以 cubic 为例),给定丢包率 p,吞吐 T 一一对应,T 和 p 相互依赖,这才能构成稳定的拥塞控制基础,不像 bbr 和 pixie,T 由 发送行为决定,发得越多,吞吐越大,很容易跑飞。
注意到 cubic 的 T-p 曲线下凸,随 p 增加,T 降低变慢,注意到丢包率 p 由 buffer 大小决定,buffer 越大,p 越小,这又引出 cubic 和 bbr 对 buffer 依赖的不同风格。
从 n 条流完全同步和 n 条流完全异步作为两个极端分析。
对于 cubic/aimd,给定 p,n 条流总吞吐 T(n) 在完全异步(单流丢包率 p)时的 T ( n ) = n ∗ p − 0.5 T(n)=n*p^{-0.5} T(n)=n∗p−0.5和完全同步(单流丢包率 n*p)时的 T ( n ) = n ∗ ( n p ) − 0.5 = n ∗ p − 0.5 T(n)=n*(np)^{-0.5}=\sqrt{n}*p^{-0.5} T(n)=n∗(np)−0.5=n∗p−0.5之间,上凸意味着收敛,随 bw,n 增加,所需 buffer 虽可能(仅n增加,buffer 甚至可以减少)也增加,但增速相比 bw 和 n 而言更慢。详见 交换机平方反比律,主要是引用的这篇论文:Sizing Router Buffers。
再看 bbr/pixie,给定 p,n 条流总吞吐 T(n) 在完全异步时的 T ( n ) = 1 1 − p T(n)=\dfrac{1}{1-p} T(n)=1−p1和完全同步时的 T ( n ) = 1 1 − n p T(n)=\dfrac{1}{1-np} T(n)=1−np1之间,下凸意味着发散,随着 bw,n 增加,所需 buffer 越大,bbr 限制 cwnd 作为 secondary controller 基于此。
但随网络规模扩大,n 必然增加。
把上面的画成图看一下(原始推导采用高斯分布定量计算,不太直观,我这里采用凸凹性定性分析):
再重复,bbr 就是一个温和版的 pixie。
改进?还是要回到 aimd,正如 bbr2,bbr3 所做的。增加灵敏度也是必须的,哪个拥塞能持续配置参数那么久还不介入,所以还是我那个自适应 maxfilter win 沾边儿:提高 bbr 灵敏性,也不能光感知下降而不弥补上升,参见这篇:bbr2 cruise 阶段的 inflight 补偿。
说白了,bbr 就像是猜硬币正反时为了更精确而引入了地转偏向力,最后其实还不如猜 50%,于是 bbr 最终也还是回归了 aimd。
如果你想让吞吐表现得良好,又不想用 pixie,那么请用 bbr1,而不是 bbr2,bbr3,因为后面这两个是做拥塞控制的,bbr1 是做传输加速的。
最后说说如何测试。
如果你没有真实环境而非要用 Linux tc 工具模拟,千万不要再用 netem loss random 1%,netem loss 1%,这种随机丢包只能应付一下经理,一定要用 4-state markov,它的配置如下:
tc qdisc add dev eth0 root netem loss state $p13 $p31 $p32 $p23 $p14
其中状态 1,2,3,4 分别为:
这就能更逼真地模拟实际中的突发拥塞丢包和随机噪声丢包交错对 cc 的影响了,而 cc 的表现更加不同。
此外,用 iperf3 而不是 iperf,观察 Retr 就能估算重传率和丢包率了。
皮鞋没有蹬上,露着白袜子。
浙江温州皮鞋湿,下雨进水不会胖。