彻底解决 IDC Incast

Incast 即同时多打一，多个 host 同时发起报文阻塞了 buffer，引发了微突发，造成了 buffer overflow 和 延时抖动。

Incast 多发生在 IDC，属于一种"同步的"规则行为，只有在 IDC 这种确定性环境才更容易发生。对于广域网，高统计复用率的行为本身是随机异步的，天然化解了 Incast.

增大 buffer 是缓解 Incast 的手段，但不能解决根本问题。虽缓解了丢包，但延时仍增加，无论重传延时还是大 buffer 排队延时，都伤害了延时敏感业务。

学着 Aeolus 的样子，捕捉下 Incast 业务特征。

既然 Incast 流量要那么多 host 扇入，必有每个 host 扇入数据量趋小的趋势，大约每个 host 只需发送 1，2 个数据包。当然，这需要数据佐证，不妨假设每个 host 只发 2 个 1000 字节的数据包。

假设交换机 buffer 有 3MB，大约 3000 扇入即可导致 buffer overflow。大于 3000 的扇入会导致丢包，进而在 RTO 后重传，这无法避免。buffer 的意义在吸收突发，有限 buffer 吸收突发的能力存在上限。

整个 Incast 事务的完成延长一个 RTO 并非本质伤害，本质伤害是在此期间 buffer 满载，造成其它延时敏感流量超时。

Incast 问题的根本解法是 “不要同时扇入”，将多个扇入分摊在多个 RTT 随机产生是高尚的。
具体如何分摊？万事不决用随机。

由于 IDC 内部网络信息是确定性已知的，假设扇入 host 到 target 的测量 RTT 为 50us，RTO 为 2*RTT，即 100us，只需要将多个扇入随机分配在 0～RTO 的时间段就好了：

• S = { 0 , 1 , 2 , 3 , . . . 100 } ， T s t a r t = r a n d o m ( S ) S=\{0,1,2,3,...100\} ， T_{start}=random(S) S={0,1,2,3,...100}，Tstart​=random(S) ，同一个 host 两个包 pacing 发送。

结局是高尚的：

• 所有扇入流量在 2*RTT 时间段内均匀到达共享链路 buffer，保持 buffer 均匀少占用，降低了抖动。且平铺在越长的时间段，buffer 占用越少，引入时延越少。

以 10Gbps 瓶颈带宽分析随机延迟 xmit 的效果。

简单计算，10Gbps 瓶颈链路每 100us 即可放出 1000 个 1000B 个数据包，若 10us 量级的 RTT，以 50us 为例，若均匀平铺 500 个数据包在 50us，可保证平均无排队放行，若允许统计突发轻微排队 1MB buffer，依照排队论，平均队长：

$L_q=\frac{{\lambda }^2}{\mu (\mu -\lambda )}=1000000=\frac{{\lambda }^2}{500000(500000-\lambda )}$

解出 $\lambda =499999.5\approx 500000$

即平均到达率 500pkts/50us 即可。意思是 50us 内泊松到达 500 个 1000B 的数据包，简单起见，随机平铺即可等价。

根据排队论公式，平均队长受 λ 影响极大，而 λ 最大只能接近但又不能过于接近于瓶颈带宽，然而瓶颈带宽受收敛比影响，不稳定。只能用 “拉长的平铺时间” 来等效。 RTT 等效即可：

• 保守等效：反正 Incast 也至少需要 RTO 时间完成事务，直接在 RTO=2*RTT 时间段平铺。
• 激进等效：考虑到允许排队，中大容量 buffer 只要在 1*RTT 时间平铺即可极大缓解 Incast 问题。

于是，即使不知道 RTT 的明确量级，流首包随机延时 5us～10us 甚至 1us～5us 发送，设为 α ，也将能缓解 Incast 大部分问题。

平铺扇入增加的随机延时并不会改变 FCT 分布。若同时到达，Incast 丢包重传也会延后完成时间，不如主动延后扇入，减少 buffer 突发占用，减少了丢包也就提供了带宽总利用率，降低了损耗。同样的时间，有丢包就是净损，该净损的端到端体验就是延时增加，不仅 Incast 流量延时增加，所有流量延时都增加。

画一个演进图：
谁触发开始发送前的随机等待呢？业务自己随机延时 socket write，or 传输协议随机延时 xmit？各有利弊。这本是 IDC 特定 Incast 场景的应对策略，业务触发随机延时可保持精确，业务最知道自己是不是 Incast。但传输协议触发亦可保持对业务透明。

IDC 传输协议可无条件只对一条流前 2 个数据包随机延时 xmit，类似 Aeolus 的思路但效果却与 Aeolus 相反。Aeolus 线速发送首窗，赌注由 ECN 机制兜底，而应对 Incast 则随机延时首包，赌注由不堵 buffer 不丢包兜底。得失无需仲裁。

为躲避 Incast 危害，不得不退回 CSMA/CD，海量扇入 Incast 场景，确实就是 buffer 冲突，所以 CSMA/CD 本就合理。

Incast 本质是对 buffer 的大规模并发，大规模并发，退避，还是退避。

昨晚写了一篇解决 Incast 的不彻底方案，那么今天肯定要聊聊彻底方案了。

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