3. 拥塞控制原理

3.1 网络拥塞的成因：从微观排队到宏观崩溃

拥塞的本质是对链路或节点资源的瞬时需求超过了可用容量。在 RoCE（RDMA over Converged Ethernet）网络中，这一矛盾被高速传输与无损语义进一步放大。理解拥塞成因需要从三个层面展开：

• 流量突发（Microburst）：即使平均带宽利用率只有 40%，毫秒甚至微秒级的突发流量也可能瞬间打满交换机出端口缓存。RoCE 的 PFC（优先级流控）机制会因缓存阈值触发反压，导致拥塞树向上蔓延。
• 多对一通信（Incast）：在分布式存储或 AI 训练场景中，多个节点同时向同一聚合交换机发送数据。当并发度超过交换机缓存深度时，数据包被迫丢弃（即使启用了 PFC，也可能因缓冲池耗尽而触发丢包）。
• 长肥管道中的窗口失配：RoCE 依赖无损传输，但端到端拥塞控制（如 DCQCN）依赖 ECN 标记和定时器。当瓶颈链路的带宽时延积（BDP）远大于发送窗口时，拥塞信号反馈滞后，发送端无法及时降速。

下图展示了拥塞从产生到扩散的典型路径，以及各层机制的作用位置：

3.2 拥塞控制的目标：公平、效率与低延迟的三角平衡

拥塞控制并非简单地“降低发送速率”，而是在三个相互制约的目标之间寻找最优平衡点：

这三个目标在 RoCE 网络中往往互相冲突。例如，为了追求极致带宽效率而让发送端激进地增加速率，会迅速填满交换机缓存，导致排队延迟上升；反之，过度保守的速率控制虽然降低了延迟，却让链路利用率跌至 70% 以下。优秀的拥塞控制算法需要像“自动驾驶”一样，根据实时网络状态动态调整速率，在三角区间内寻找当前最优工作点。

3.3 拥塞控制算法分类：从端到端到逐跳机制

RoCE 网络中的拥塞控制算法可以从控制位置和反馈机制两个维度进行分类。理解分类有助于在实际部署中根据业务特征选择合适方案。

3.3.1 按控制位置分类

• 端到端拥塞控制：发送端根据网络反馈（ECN 标记、CNP 报文）调整发送速率。代表算法：DCQCN（RoCE v2 的事实标准）、TIMELY（基于 RTT 梯度）、HPCC（基于 INT 带内遥测）。这类算法部署灵活，但反馈延迟较大。
• 逐跳拥塞控制：每个交换机节点独立检测拥塞并采取局部动作（如 PFC 暂停、QCN 反压）。响应速度快，但可能引发公平性问题。
• 混合方案：结合端到端与逐跳机制。例如，DCQCN 同时使用 ECN（端到端标记）和 PFC（逐跳保护），形成“粗粒度降速 + 细粒度保护”的双层防线。

3.3.2 按反馈信号分类

3.3.3 按速率调整策略分类

速率调整策略对比：
─────────────────────────────────────────────────────
AIMD（加性增/乘性减）      : DCQCN 的基础策略
   - 增加阶段: rate += AI (如 4 Mbps/次)
   - 减少阶段: rate *= (1 - β) (如 β=0.5)

BIC/CUBIC（二分搜索）      : 适用于长肥管道
   - 窗口增长呈凹函数，适合高 BDP 场景

DCTCP（显式拥塞阈值）      : 基于 ECN 标记比例
   - 根据标记概率平滑调整窗口

基于 INT 的精确控制        : HPCC 直接计算目标速率
   - 利用队列长度和链路利用率精确求解
─────────────────────────────────────────────────────

3.4 案例复盘：一次典型的拥塞控制失效分析

某互联网公司部署 100G RoCE 集群用于分布式存储（Ceph），业务反馈“写入延迟从 2ms 飙升至 200ms”。排查过程如下：

1. 初步检查：交换机端口无丢包计数，但 PFC 暂停帧计数持续增长。说明网络在“丢包→PFC 保护”模式下运行，但端到端降速未生效。
2. 深入分析：抓包发现 CNP（拥塞通知包）发送正常，但发送端网卡（NIC）未响应 CNP 降速。检查固件版本，发现 NIC 的 DCQCN 参数中 cnp_handle 被误设为 0（禁用）。
3. 根因定位：运维团队在升级固件时，默认配置覆盖了原有调优参数，导致 DCQCN 的降速功能被静默关闭。PFC 虽然阻止了丢包，但拥塞信号无法闭环，队列持续堆积。
4. 解决方案：重新配置 DCQCN 参数，并增加监控告警：当 PFC 暂停帧速率超过 1000 帧/秒时触发通知。