IDC Incast 的不彻底解决-CSDN博客

都很烦 Incast，但解法都属见招拆招型，case by case 不高尚。

Incast 导致 buffer 溢出丢包，就增加 buffer。但问题不是丢包，而是延时增加，业务不感知丢包却感知延时。buffer 增加的效果是 “让事情不发生”，掩盖问题，而加深了恶果。

减少 min RTO？正视丢包不可避免，那就加快重传，尽快恢复，看似比加 buffer 强，但 min RTO 多少合适呢？问题不在 min RTO，问题在 TCP min RTO。若单纯按 RTT 算 RTO，算出来是多少就是多少，根本不会有 min RTO 的概念，是 TCP Delay ACK 要求 RTO 必须有一个下界。

更有，对于 TCP，时间戳，RTO 精度本是 ms 级，特别对于 Linux kernel TCP 不支持浮点数，更难以支撑 us 级别的计算精度。对于 IDC 高速短程网络，整数运算 us 级精度损失将会被放大，修改 Linux kernel TCP 是大工程。

再说双边用户态 TCP。仍要试图找到一个合理的 min RTO。既然双边了，为何还紧抓着 min RTO 不放？双边方案超级多。脱离 1981 年 RFC793 标准 TCP 才能飞得更高。

TCP flags 有几个 bit 保留，用掉两个 bits 作为 “RTT 测量” 很高尚。比如 01 为 request，10 为 response，当 TCP 收到 01 时，须无条件回复携带 10 的立即 ACK，就避开了 Delay ACK 的影响，安心测 RTT。

再者，双边可无协商无条件支持 us 精度，用户态实现亦可随意进行浮点运算，有这般物件儿，死抱着 “优化 Linux kernel TCP” 的思路，无疑不高尚。这其中，每去掉一个词，路子就敞亮一些，依次去掉 Linux，kernel，TCP 试试看。

对 Incast 本身，还有个 cwnd 的问题。当前 Linux TCP 不支持 cwnd < 1，这会使 Incast 趋重。在一个 cwnd >= 1 的传输系统中，每次触发传输事件后，总会有至少 1 个数据包发出。即使按照包守恒计算也是如此。

200:1 的 Incast 场景，若 100 个数据包已填满 buffer，任何 TCP ACK 到达均会导致额外至少 1 个数据包发出，从而加剧 buffer overflow。即便 rate-based 算法已算出一个极小的 pacing rate，据 BDP 反算的 cwnd 仍向上取整到 1。

TCP 不支持下面一种机制，以 pacing rate 为 primary control，以 BDP 以为 cwnd，若 cwnd < 1，则在对应发送时间步长的后端发出该数据包，比如 cwnd = 0.1，即 1 个 RTT 发送 0.1 个数据包，数据包不拆分，就延长时间，即 10 个 RTT 发送 1 个数据包，那么在 10 个 RTT 后，发出 1 个数据包即可。前面有 9 个 RTT 的空窗期，Incast 大概率可缓解。

以上举措可用于初始化pacing rate，不必发觉丢包才测算，比如扇出的每个 host 均以 cwnd = 0.5 发送，10 个 RTT 发送 5 个数据包，便可在 10 个 slot 里随机安排以缓解甚至解决 Incast 大问题了。

似乎很少有这方面的调研和实现。来者之可追。

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