TCP Vegas 收敛性与吞吐

Posted 2022-11-18 dog250

昨天下班路上发个朋友圈：

TCP Vegas 算法作为一个 Delay-based 算法，与 Loss-based 算法的处理完全不同。由于 Delay 并非明确信号，无法找到触发 AIMD 的时机。Vegas 采用 AIAD。

Vegas 思想相当极简：

• 当排队尚未严重到一定程度，AI 递增 cwnd。
• 当排队严重到一定程度，AD 递减 cwnd。

论文：https://cseweb.ucsd.edu/classes/wi01/cse222/papers/brakmo-vegas-jsac95.pdf

AIAD 是不收敛的，Vegas 为何收敛呢？关键在于 “一定程度”，这 “排队到一定程度” 并非固定事件，它随 Buffer 的使用及多条流分别占用 Buffer 的比例而变化。

本文先证明 Vegas 收敛性，再针对 Linux Vegas 实现做一个优化，斧正由于 Linux 内核拥塞状态机框架的局限而导致的带宽利用率损失。

先看收敛性。

设流 i 窗口为 Wi，带宽为 bi，固定传播时延 r，队列中的数据量为 Bi，排队时延 Di，则：

$W_i=B_i+b_i\ast r$

$b_i=\frac{W_i}{R_i}=\frac{W_i}{D_i+r}$

现推导两条流的收敛情况。由于共享 Buffer，两条流的排队时延是相同的，设 D = Di，则：

$b_i=\frac{W_i}{D+r}$

此外，两条流共享带宽，且带宽利用率 100%，设总带宽为 1，则：

$b_1+b_2=\frac{W_1}{D+r}+\frac{W_2}{D+r}=1$

给定任意 W1 和 W2，均可求的 b1，b2，进而求得 B1，B2。
把满足以下条件的所有点 P(W1, W2)描成线：
L1： $\alpha =B_1$
L2： $\beta =B_1$
L3： $\alpha =B_2$
L4： $\beta =B_2$

即下图：

下面看为什么 L1～L4 是双曲线形式。
通过 Vegas 稳定条件 $\alpha \le Diff=W\ast (\frac{R}{r}-1)\le \beta$ 构造等式：

$\alpha =W\ast (\frac{R}{r}-1)$

可得：

$W=\alpha \ast \frac{r}{R-r}$

写出 W1 的表达式，并用 W2 的表达式表示 R：

$W_1=\alpha \ast \frac{r}{\frac{W2}{b_2}-r}$

看一下 W 和 b 的大致关系，如果 W 和 W/b 之间正相关，W1 和 W2 则构成一条大致双曲线，就能看出 L1～L4 就是那个样子。

显然，D 是 W 的增函数：$D=f(W)$，根据 b 和 W 的关系 $b=\frac{W}{D+r}=\frac{W}{f(W)+r}$，两边同时除以 b：

$\frac{W}{b}=f(W)+r$

可见，W 和 W/b 正相关(另一种解释是，W 占比越大，b 的加速比越小)。于是 $W_1=F(W_2)$ 大致就是一条双曲线。

最终，很显然，对于流 1，Vegas 的稳定状态要求 W1 在 L1 和 L2 之间，对于流 2，Vegas 的稳定状态要求 W2 在 L3 和 L4 之间，图中 1 和 2 的区域即收敛区域。

这个区域围绕在公平线两边，说明 Vegas 是收敛的。

这张图的结论如下：

• 带宽利用率 100%。
• 稳定收敛到公平。

看起来不错，高效又公平，剩下的工作就是在各种场景下调参，找到最优的 α ， β 。

这意味着 Vegas 不需要 AIMD。但对于 Linux Vegas 实现，在 4.9 内核前，却避不开 AIMD。

Linux 4.9 之前，TCP 内置的拥塞状态机对拥塞控制算法的假设是 Loss-based，在 Recovery 状态，prr 算法无条件将 cwnd 退避到 ssthresh。

直到 BBR 引入 cong_control 回调完全接管拥塞状态机，一切才高尚。既然 Delay-based Vegas 已经自行完成了收敛，AIMD 岂不多余？

Delay-based Vegas 既然用 Delay 变化控制拥塞，理想情况下即无拥塞，否则 Vegas 即失效，因此，丢包一定不是拥塞导致，执行守恒足够了。

改个移除 AIMD 的版本：
https://github.com/marywangran/tcp-vegas-plus

这是一个朴素的 Vegas，但真实。核心有三个：

• cong_control 全权接管拥塞状态机处理。
• RTO 后需 reset 掉 minRTT。RTO 需很久，Fast Retransmit 和 TLP Retransmit 均未触发，可能遭遇了路由重收敛。
• 发生丢包时，在 Recovery 阶段执行数据包守恒。

跟我上周的 caohejing 算法类似，caohejing 算法也一样需要调参，比如 5% 增益和减损阈值。不同的是 caohejing 算法是 Rate-based，丢包会反馈在 Delivery rate ，自动收敛。Vegas 还是 ACK 驱动，Recovery 状态需主动执行守恒。

Delay-based Vegas 的 AIAD 可以收敛吗？可以。Vegas 需要丢包时 MD 吗？不需要。为什么代码里看起来需要 MD 呢？因为 Linux TCP 拥塞控制框架的局限，以及实现者趋向保守。那么 Vegas 面临丢包时需要如何做呢？执行数据包守恒即可。 这鞋子能跳舞吗？呱唧，呱唧，啪！不一般，我喜欢，日泰皮鞋！

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