cwnd ＜ 1 时的拥塞控制

简单理解，如果经过同一转发节点的流数量大于 $\frac{BDP}{mss}$ ，理论 cwnd 会小于 1，但对于不支持浮点运算的 Linux kernel 而言，处理小数非常麻烦，即使通过缩放技术完成了运算，如何处理小于 1 的 cwnd 依然存在问题。

比如 cwnd = 0.1，即 10 个 RTT 发送 1 个报文。问题在于要在第几个 RTT 发送这个报文呢？ 如果所有流的发送端都在某个固定的 RTT 发送 1 个报文，cwnd = 0.1 的效果只不过是将拥塞延后了几个 RTT。

高尚的做法应该采用随机退避，这简直回到了 CSMA/CD 的策略，原始且精妙。

比如 cwnd = 0.1， sender 应该在接下来第 random(0, 10) 个 RTT 发送 1 个报文；cwnd = 0.02， sender 即在第 random(0, 50) 个 RTT 发送 1 个报文。

相比之下，Linux kernel TCP 将 cwnd 约束在 max(1, cwnd) 略激进，对 3MB 的 buffer，只需 3000 条流就能产生拥塞控制算法无法处理的丢包，而 30000 条流共存空见惯的现代高并发网络，仅能适配 30MB 的 buffer。

虽然 buffer 大小与流数量 n 满足平方反比律 $B=\frac{BDP}{\sqrt{n}}$ ，但对于 DC 网络的 incast 流量，多条同步流显然无法从中受益，，使多条流异步化，意义是：

• 从平方反比律对 buffer 的需求随 n 的增加递减中受益。
• 随机发送，统计复用时隙，减少冲突。

事实上，DC buffer 平方反比律，CSMA/CD 统计复用，cwnd < 1 时随机化发送 RTT 时隙，都是一回事，流要异步，不要同步！

Linux Kernel TCP 不支持浮点数，TCP cwnd，pacing rate 的计算必须取整，这损失了精度，但 RFC 也是这么规范 cwnd 的，这明显已经不适合 DC 网络这种微秒级网络了，相对粗旷的 cwnd 规范是面向 Internet 的，但现在 DC 显然是另一种性质的网络。

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