TCP CUBIC 窗口增长机制

🧑‍💻 User

Over the years, networks have improved with link speeds increasing tremendously. This has called for changes in the TCP congestion control mechanisms mainly with a desire to improve link utilization.

We can see that TCP Reno has low network utilization, especially when the network bandwidth is high or the delay is large. Such networks are also known as high bandwidth delay product networks.

To make TCP more efficient under such networks, many improvements to TCP congestion control have been proposed. Now we will look at one such version, called TCP CUBIC, which was also implemented in the Linux kernel. It uses a CUBIC polynomial as the growth function.

Let us see what happens when TCP experiences a triple duplicate ACK, say at window=W max. This could be because of congestion in the network. To maintain TCP-fairness, it uses a multiplicative decrease and reduces the window to half. Let us call this W min.

Now, we know that the optimal window size would be in between W min and W max and closer to W max. So, instead of increasing the window size by 1, it is okay to increase the window size aggressively in the beginning. Once the W approaches closer to W max, it is wise to increase it slowly because that is where we detected a packet loss last time. Assuming no loss is detected this time around Wmax, we keep on increasing the window a little bit. If there is no loss still, it could be that the previous loss was due to a transient congestion or non-congestion related event. Therefore, it is okay to increase the window size with higher values now.

This window growth idea is approximated in TCP CUBIC using a cubic function. Here is the exact function it uses for the window growth:

W(t) = C(t-K) ³ + W _max

Here, W max is the window when the packet loss was detected. Here C is a scaling constant, and K is the time period that the above function takes to increase W to Wmax when there is no further loss event and is calculated by using the following equation:

K = $\sqrt³{\frac{W\max\beta}{C}}$

It is important to note that time here is the time elapsed since the last loss event instead of the usual ACK-based timer used in TCP Reno. This also makes TCP CUBIC RTT-fair.

References

CUBIC: A New TCP-Friendly High-Speed TCP Variant

https://www.cs.princeton.edu/courses/archive/fall16/cos561/papers/Cubic08.pdf Links to an external site.

🤖 Assistant

TCP CUBIC 费曼学习法自检清单

📋 Checklist（自检清单）

第一部分：背景理解

[ ] 1. 我能解释为什么传统 TCP Reno 在某些网络中效率低下吗？
[ ] 2. 我能用自己的话解释什么是”高带宽延迟积网络”(High Bandwidth-Delay Product Networks)吗？
[ ] 3. 我能说出 TCP CUBIC 被设计出来要解决什么问题吗？

第二部分：核心机制理解

[ ] 4. 当发生三次重复ACK (Triple Duplicate ACK) 时，TCP CUBIC 如何响应？
[ ] 5. 我能解释 W_max 和 W_min 分别代表什么吗？
[ ] 6. 为什么说”最优窗口大小在 W_min 和 W_max 之间，且更接近 W_max”？

第三部分：窗口增长策略

[ ] 7. 我能用”快-慢-快”三个阶段描述 TCP CUBIC 的窗口增长策略吗？
[ ] 8. 为什么在接近 W_max 时要”慢慢增加”窗口？
[ ] 9. 为什么超过 W_max 后又可以”激进增加”窗口？

第四部分：数学公式理解

[ ] 10. 我能写出并解释 TCP CUBIC 的窗口增长公式吗？
[ ] 11. 公式中的 C、K、t、W_max 各代表什么？
[ ] 12. K 的计算公式是什么？它的物理意义是什么？

第五部分：关键特性

[ ] 13. TCP CUBIC 的时间计算方式与 TCP Reno 有何不同？
[ ] 14. 我能解释什么是”RTT公平性”(RTT-fairness)吗？
[ ] 15. 我能向一个完全不懂网络的人画图解释 TCP CUBIC 的窗口变化曲线吗？

✅ 答案与详解

问题1：我能解释为什么传统 TCP Reno 在某些网络中效率低下吗？

答案：
TCP Reno 使用线性增长策略（每个RTT窗口+1），在高带宽或高延迟网络中，需要很长时间才能充分利用链路容量。例如，一个10Gbps的链路，Reno可能需要数千个RTT才能填满管道，导致链路利用率(Link Utilization) 很低。

问题2：我能用自己的话解释什么是”高带宽延迟积网络”吗？

答案：
带宽延迟积 (Bandwidth-Delay Product, BDP) = 带宽 × 往返时延(RTT)

它表示网络”管道”中能同时容纳的数据量。高BDP网络就像一条又宽又长的高速公路，需要大量数据才能”填满”。例如：

带宽：1 Gbps
RTT：100ms
BDP = 1Gbps × 0.1s = 100Mb = 12.5MB

问题3：TCP CUBIC 被设计出来要解决什么问题？

答案：
解决 TCP Reno 在高BDP网络中收敛速度慢、链路利用率低的问题，让拥塞窗口能更快地增长到最优值。

问题4：当发生三次重复ACK时，TCP CUBIC 如何响应？

答案：
执行乘性减少 (Multiplicative Decrease)，将拥塞窗口减半：

丢包时窗口 = W_max
减半后窗口 = W_min = W_max × β（通常β=0.5）

这保持了与其他TCP版本的TCP公平性 (TCP-fairness)。

问题5：W_max 和 W_min 分别代表什么？

答案：
| 符号 | 含义 |
|———|———|
| W_max | 检测到丢包时的拥塞窗口大小（上次的”天花板”） |
| W_min | 乘性减少后的窗口大小（W_max的一半） |

问题6：为什么说”最优窗口大小在 W_min 和 W_max 之间，且更接近 W_max”？

答案：
因为在 W_max 处才发生丢包，说明网络容量接近 W_max。减半后的 W_min 肯定太保守了，所以最优点应该在两者之间，且更靠近 W_max（网络的真实容量上限）。

问题7：用”快-慢-快”三个阶段描述 TCP CUBIC 的窗口增长策略

答案：

Code

窗口增长速度：

阶段1 [快]：W_min → 接近W_max
         ↓ 激进增长，快速恢复
         
阶段2 [慢]：接近 W_max 附近
         ↓ 谨慎探测，避免再次丢包
         
阶段3 [快]：超过 W_max 后
         ↓ 说明网络容量可能增加了，可以激进探索

问题8：为什么在接近 W_max 时要”慢慢增加”窗口？

答案：
因为 W_max 是上次检测到丢包的位置，说明网络在那个点附近开始拥塞。接近这个”危险区域”时，应该小心翼翼地探测，避免再次触发丢包。

问题9：为什么超过 W_max 后又可以”激进增加”窗口？

答案：
如果窗口超过 W_max 仍然没有丢包，说明：

上次丢包可能是瞬时拥塞 (Transient Congestion)
或者是非拥塞原因导致的丢包
或者网络容量已经增加了

因此可以更激进地探索新的网络容量上限。

问题10：TCP CUBIC 的窗口增长公式

答案：

$W(t) = C(t - K)^3 + W_{max}$

这是一个三次函数 (Cubic Function)，图形呈S形曲线。

问题11：公式中各参数的含义

答案：

参数	英文	含义
W(t)	Window at time t	t时刻的拥塞窗口大小
C	Scaling Constant	缩放常数，控制增长的激进程度
t	Time	自上次丢包以来经过的时间
K	Time to reach W_max	窗口从W_min增长到W_max所需的时间
W_max	Maximum Window	上次丢包时的窗口大小

问题12：K 的计算公式及物理意义

答案：

$K = \sqrt[^3]{\frac{W_{max} \cdot \beta}{C}}$

物理意义： K 是在没有丢包的情况下，窗口从减半后的值恢复到 W_max 所需的时间。它决定了曲线的”拐点”位置。

问题13：TCP CUBIC 的时间计算方式与 TCP Reno 有何不同？

答案：

特性	TCP Reno	TCP CUBIC
时间基准	基于ACK (ACK-based)	基于实际时间 (Real time elapsed)
增长触发	每收到一个ACK	根据时间流逝计算

TCP CUBIC 使用自上次丢包以来经过的实际时间，而不是ACK数量。

问题14：什么是”RTT公平性”(RTT-fairness)？

答案：
RTT公平性指不同RTT的连接能获得相近的带宽份额。

TCP Reno：RTT短的连接增长更快（因为ACK回来得快），对长RTT连接不公平
TCP CUBIC：使用实际时间而非ACK，所以不管RTT长短，窗口增长速度相同，实现了RTT公平

问题15：TCP CUBIC 窗口变化曲线图解

答案：

Code

拥塞窗口
    ^
    |                    ___----  (阶段3: 快速探索)
    |                 __/
W_max|_ _ _ _ _ _ _ _/_ _ _ _ _ _ (阶段2: 谨慎接近)
    |              /|
    |            /  |
    |          /    |
    |        /      |
W_min|_ _ _ /        |  (阶段1: 快速恢复)
    |     |         |
    |     |         |
    +-----+---------+---------> 时间
        丢包      K时刻
        事件    (到达W_max)

曲线特点：

开始时斜率大（快速增长）
接近 W_max 时斜率趋近于0（平缓）
超过 W_max 后斜率又变大（继续探索）

🎯 终极自检

如果你能不看答案，向一个朋友解释清楚以下内容，说明你真正理解了：

“TCP CUBIC 就像一个聪明的司机。当发生事故（丢包）后，他先快速加速恢复到接近上次出事的速度，然后在那个危险速度附近小心驾驶，如果发现路况变好了（没再出事），就继续加速探索更高的速度。”