4. 拥塞控制基础：目标、拥塞窗口与关键性能指标
在深入 RoCEv2 的拥塞控制机制之前，必须先建立一套通用的分析框架。拥塞控制并非孤立的算法，而是围绕三个核心问题展开的系统工程：控制什么（拥塞窗口）、为了什么（性能目标）、如何衡量（性能指标）。只有将这三者统一理解，后续学习 DCQCN、TIMELY 等具体算法时才能看清其设计取舍。
4.1 拥塞控制的目标：效率与公平的平衡
拥塞控制的根本目标不是“消除排队”，而是在共享链路中维持高利用率的同时，避免因过度注入流量导致网络崩溃。对于 RoCEv2 这类运行在无损以太网上的协议，目标被进一步细化：
- 最大化瓶颈带宽利用率：使瓶颈链路始终处于“忙而不堵”的状态，即队列深度保持在一个较小但非零的范围内。
- 最小化端到端时延：尤其是对 RDMA 读操作，时延直接决定了分布式训练或存储集群的同步效率。
- 保证流间公平性：避免某些“大象流”长期霸占带宽，导致“老鼠流”（如控制消息）饿死。
- 避免 PFC 级联死锁：这是 RoCEv2 特有的目标——拥塞控制必须在 PFC 暂停帧扩散之前介入，否则可能引发全网范围内的头阻塞。
值得注意的是，这些目标之间存在内在矛盾。例如，追求极低时延意味着必须保持极短队列，但这会降低链路对突发流量的吸收能力，从而牺牲部分带宽利用率。优秀的拥塞控制算法本质上是在这个矛盾空间中寻找动态平衡点。
4.2 拥塞窗口：发送行为的“节流阀”
拥塞窗口（Congestion Window, CWND）是发送端控制在途未确认数据量的阀门。在 RoCEv2 中，CWND 的单位通常是 包数量（而非 TCP 的字节数）。发送端允许发送的数据量由以下公式决定：
允许发送的数据量 = min(CWND, 接收端通告的可用缓冲区)拥塞窗口的调整遵循经典的加性增/乘性减（AIMD）框架，但 RoCEv2 的具体实现（如 DCQCN）引入了更精细的步进控制：
- 增加阶段：当收到正向反馈（如 ECN 标记率低于阈值）时，CWND 按线性或逐步递增，探测剩余带宽。
- 减少阶段：当收到负向反馈（ECN 标记率超标）时，CWND 按比例快速下降，通常乘以一个小于 1 的因子（如 0.5 或更激进）。
- 恢复阶段：为避免拥塞后链路空转，算法会通过定时器或额外确认机制逐步恢复 CWND，而非像 TCP 那样从慢启动重新开始。
下图展示了拥塞窗口在理想状态下的动态调节过程，以及它与队列深度、链路利用率之间的关系：
上图揭示了拥塞窗口调节的核心矛盾：窗口增长过快会导致队列堆积和时延飙升；窗口下降过猛则会造成链路空窗期，浪费带宽。RoCEv2 的各类算法（DCQCN、TIMELY、HPCC）本质上都是在优化这条蓝色曲线的“爬升斜率”和“下降幅度”。
4.3 关键性能指标：吞吐量、时延与丢包率
衡量拥塞控制效果需要一套可量化的指标体系。在 RoCEv2 场景下，三个指标相互关联，构成一个“不可能三角”的约束关系。
| 指标 | 定义 | RoCEv2 场景下的特殊含义 | 理想目标 |
|---|---|---|---|
| 吞吐量 | 单位时间内成功传输的数据量（Gbps） | 受 PFC 暂停影响，实际吞吐可能远低于链路带宽 | 接近瓶颈链路带宽的 90% 以上 |
| 时延 | 数据从发送端到接收端的耗时（μs） | 包含排队时延；无损网络中队列可能无限增长 | 无拥塞时接近基础时延；拥塞时增长可控 |
| 丢包率 | 丢失数据包占总发送量的比例 | RoCEv2 设计目标为“零丢包”，但 PFC 暂停可视为“隐式丢包” | 严格为 0（物理层误码除外） |
4.3.1 吞吐量：不仅仅是“跑满带宽”
在无损网络中，吞吐量指标需要关注两个层面：瓶颈链路利用率和有效吞吐量。前者指物理链路上实际传输的比特率，后者则剔除了重传、PFC 暂停造成的空档期。一个常见的误区是：只要发送端持续发送，就认为吞吐量达标。实际上，如果 PFC 暂停帧频繁触发，发送端虽未停止发送，但链路利用率可能已大幅下降。
有效吞吐量 = 实际传输的有效数据量 / 总耗时
链路利用率 = 实际传输比特数 / (链路带宽 × 时间)4.3.2 时延：从微秒级到毫秒级的灾难
RoCEv2 的时延敏感度远高于 TCP。一个典型的 RDMA 写操作要求在 10μs 量级完成，而一旦发生拥塞，排队时延可能迅速膨胀到数百微秒甚至毫秒级。时延指标通常关注：
- 基础时延（Base Latency）：空载时的端到端时延，由线缆、交换机和网卡处理决定。
- 尾时延（Tail Latency）：99 分位或 99.9 分位的时延，对分布式同步至关重要。
- 时延抖动（Jitter）：时延的方差，影响存储集群的 IO 稳定性。
4.3.3 丢包率：RoCEv2 的“零容忍”
虽然 RoCEv2 运行在无损网络上，但丢包并非完全不存在。可能的原因包括：物理层误码、配置错误的 PFC 优先级、或交换机内部缓冲区溢出（如因 PFC 死锁导致）。一旦发生丢包，RDMA 的可靠传输（RC 模式）会触发重传，但重传代价极高——不仅消耗带宽，还会造成严重的时延尖峰。
因此，RoCEv2 拥塞控制的一个核心评价标准是：能否在 PFC 触发之前就完成流量调节。如果拥塞控制算法足够灵敏，交换机队列深度应始终保持在 PFC 阈值以下，从而保证物理丢包率为零。
4.4 案例：一次典型的拥塞事件复盘
假设一个 40Gbps RoCEv2 存储集群，多台服务器同时向一台存储节点发起读请求。初始时各发送端 CWND 均为 64，链路空闲。
- 拥塞形成：10 台服务器同时发送，总注入速率达到 40Gbps，但存储节点的网卡处理能力仅为 30Gbps，瓶颈出现在接收端。
- 队列堆积：交换机出口队列开始增长，从 0 逐渐增加到 200KB。
- ECN 标记：当队列深度超过交换机设定的 ECN 阈值（如 100KB），交换机开始对数据包打 ECN 标记。
- 发送端响应：接收端收到 ECN 标记后，在 CNP（Congestion Notification Packet）中反馈给发送端。发送端收到 CNP 后，将 CWND 乘以 0.5（从 64 降至 32）。
- 队列回落：所有发送端窗口减半后，注入速率降至 20Gbps，队列逐渐排空，时延回落。
- 带宽恢复：发送端在未收到 CNP 后，每经过一个 RTT 将 CWND 增加 1，逐步恢复到 64，再次探测带宽。
这个案例展示了拥塞控制的完整闭环。但实际中，问题往往出现在第 4 步——如果 CNP 反馈延迟过大（例如因接收端 CPU 繁忙），发送端可能持续以高窗口发送，导致队列溢出并触发 PFC。
4.5 常见误区与复盘
无损网络只是将拥塞的表现形式从“丢包”转移为“时延增长”和“PFC 暂停”。真正的拥塞控制目标是避免 PFC 触发，而非仅仅避免丢包。
在分布式训练场景中，AllReduce 操作的完成时间取决于最慢的节点。即使平均时延很低，只要尾时延出现尖峰，整体性能就会严重劣化。
如果瓶颈不在发送端而在网络中间节点，盲目增大 CWND 只会加剧队列堆积，最终触发 PFC 或 ECN，反而降低有效吞吐。CWND 的最优值应等于带宽时延积（BDP），即：
CWND_optimal = 瓶颈带宽 × 往返时延。