无损网络与拥塞控制 —— PFC、ECN、DCQCN

第 5 章 5.8 和第 6 章 6.3 都提到 PFC / ECN——这两个机制是 RoCE / AI 集群”最难调”的部分。本文专题展开。

为什么需要”无损”

1
2
3
4
5
6
7
8
9
传统以太网：默认丢包
  → TCP 看到丢包就缓速 + 重传
  → 重传增加延迟，降低吞吐
  → 应用层无感知

RDMA：不容忍丢包
  → IB go-back-N 重传：1 包丢了，整窗重传
  → 性能崩塌
  → 应用层（NCCL / vLLM）卡住

RDMA 协议假设网络无损——这是 IB 物理层 credit-based 流控的”传统”。当 RDMA 跑在以太网（RoCE）上时，必须用其他机制做出”无损”假象。

三件套：PFC + ECN + DCQCN

graph TB
  PROBLEM[拥塞产生]
  PFC[PFC
链路级背压
瞬时止血]
  ECN[ECN
端到端拥塞标记
主动降速]
  DCQCN[DCQCN
拥塞控制算法
速率管理]
  
  PROBLEM --> PFC
  PROBLEM --> ECN
  ECN --> DCQCN
  PFC --> NL[网络无丢包]
  DCQCN --> NL

PFC 是急救，ECN + DCQCN 是”治本”。两者必须配合用。

PFC：Priority Flow Control

PFC 是 IEEE 802.1Qbb——链路级、按优先级的背压：

graph LR
  A[发送方] -->|流量| B[交换机]
  B -.->|缓冲快满| A
  A -.->|PAUSE 帧| C[暂停发送]

工作流程：

1
2
3
4
1. 交换机入口 buffer 接近某优先级阈值
2. 交换机向上游发"PAUSE 帧"（指定优先级）
3. 上游收到 PAUSE → 该优先级流量暂停
4. buffer 排空到下阈值 → 发"RESUME"

8 个优先级（CoS）

1
2
3
4
5
6
7
PFC 用以太网帧的 Priority 字段（VLAN tag 或 DSCP 映射）：
  优先级 0-7，每个独立 PAUSE/RESUME
  
典型映射：
  Priority 3 / DSCP 26：     RoCE 流量
  Priority 6 / DSCP 48：     ECN 控制流
  其他优先级：               TCP / 管理流量

PFC 阈值参数

1
2
3
4
5
6
7
8
XOFF 阈值：     buffer 占用达此点 → 发 PAUSE
XON 阈值：      buffer 占用降此点 → 发 RESUME
Headroom：     从 PAUSE 发出到对方真正停的"在路上"包的缓冲

阈值设计原则：
  Headroom 必须 >= 端到端 RTT × 链路速率
  100m 短距：headroom ~10 KB
  跨房间：    headroom ~100 KB+

PFC 的”老坑”

坑 1：PFC Storm

1
2
3
4
5
6
7
8
9
PFC 帧本身可以构成环路：
  A 发 PAUSE 给 B
  B 因被 PAUSE → 自己 buffer 满 → 发 PAUSE 给 C
  C 同理 → 发 PAUSE 给 A
  → 整个网络僵死
  
解决：
  - PFC Watchdog（厂家普遍支持）
  - Storm Control（限制 PAUSE 帧速率）

坑 2：HoL Blocking（队头阻塞）

1
2
3
4
单个流量"阻塞"导致整队列暂停：
  GPU A → GPU B 路径堵 → A 上游 PAUSE
  → A 上游所有流量都停（包括到其他 GPU 的）
  → 拥塞蔓延

PFC 的本质问题就是粒度太粗——一个优先级对应整个端口。

坑 3：跨厂家不一致

1
2
3
4
5
6
7
不同厂家交换机 PFC 参数行为略有不同：
  阈值默认值不同
  PAUSE 帧时长解释不同
  buffer 算法不同（pool-based vs queue-based）

→ 跨厂家集群调优极难
→ 万卡级集群往往一家厂家"全用同一型号"

ECN：Explicit Congestion Notification

ECN 是 RFC 3168——端到端的拥塞标记：

graph LR
  S[发送方
支持 ECN] --> P1[包
ECT=1]
  P1 --> SW[交换机
buffer 高]
  SW --> P2[包
CE=1
congestion]
  P2 --> R[接收方]
  R --> CNP[发 CNP 包
给发送方]
  CNP --> S
  S --> RATE[降速]

工作流程：

1
2
3
4
1. 发送方发包，IP 头标记 ECT（ECN-Capable Transport）
2. 交换机 buffer 占用超阈值 → 标记 CE（Congestion Experienced）
3. 接收方看到 CE → 给发送方发 CNP（Congestion Notification Packet）
4. 发送方降速

ECN 标记阈值

交换机用 WRED（Weighted Random Early Detection） 算法：

1
2
3
buffer 占用 < ECN_min：       不标记
ECN_min ≤ 占用 < ECN_max：    按概率标记
buffer 占用 ≥ ECN_max：       100% 标记

调优要点：

1
2
3
4
5
ECN_min：    通常 buffer 大小 5-15%
ECN_max：    通常 50-70%
ECN 阈值要 < PFC 阈值
  → 拥塞先触发 ECN，再触发 PFC
  → ECN 调优好 → 不用走 PFC

DCQCN：拥塞控制算法

DCQCN（Data Center QCN）= Microsoft + Mellanox 联合发明的 RoCE 拥塞控制算法（2015）：

graph TB
  S[发送方]
  S --> CHECK{收到 CNP?}
  CHECK -- 是 --> DOWN[速率减半]
  CHECK -- 否 --> CHECK2{时间窗口?}
  CHECK2 -- 慢启动期 --> UP1[加性增速]
  CHECK2 -- 快恢复期 --> UP2[乘性增速]

DCQCN 借鉴了 TCP CUBIC 的思路：

1
2
3
4
5
6
7
8
9
拥塞时：     乘性减少（MD）
平稳时：     加性增加（AI）
长时间稳定： 乘性增加（HAI，Hyperactive Increase）

参数：
  Rate_AI：     每周期增加多少（默认 5 Mbps）
  Rate_HAI：    HAI 阶段增加（默认 50 Mbps）
  Reduction Factor：减小因子（默认 0.5）
  Recovery Period：从 CNP 到开始恢复的时间

DCQCN 调优经验

1
2
3
4
5
6
默认值适合大多数场景，但极端拥塞下要调：

1. ECN_min / ECN_max 偏低 → 流量过早降速 → 利用率低
2. ECN 阈值偏高 → 拥塞已经导致 PFC → 大流量崩
3. Rate_AI 过小 → 拥塞解除后恢复慢
4. Rate_AI 过大 → 容易又拥塞

其他拥塞控制算法

DCQCN 是事实标准，但还有其他选择：

graph TB
  CC[拥塞控制]
  CC --> DCQCN[DCQCN
Mellanox 主推]
  CC --> TIMELY[TIMELY
Google
RTT-based]
  CC --> HPCC[HPCC
阿里
INT-based]
  CC --> SWIFT[SWIFT
Google]
  CC --> POSEIDON[Poseidon
NVIDIA Spectrum-X]

TIMELY（Google）

1
2
3
4
5
不用 ECN，只用 RTT：
  - 监测 RTT 变化
  - RTT 涨 → 拥塞加重 → 降速
  - 简单，不需要交换机配合
  - 但精度不如 ECN

HPCC（High-Precision Congestion Control，阿里）

1
2
3
4
5
用 INT（In-band Network Telemetry）：
  - 包头携带交换机 buffer 状态
  - 端到端精知道每跳拥塞
  - 调速精度高
  - 要求交换机支持 INT

Poseidon（NVIDIA Spectrum-X，2023）

1
2
3
4
5
NVIDIA 自己的"AI 优化拥塞控制"：
  - 配合 Spectrum-4 ASIC + ConnectX-7
  - per-packet adaptive routing
  - 比 DCQCN 更激进的"AI 流量优化"
  - 闭源（Mellanox 内部）

待补充：Poseidon 实测数据 / 与 DCQCN 性能对比。

调优实战

第 1 步：识别”是否拥塞”

1
2
3
4
5
6
7
8
9
# 看交换机 ECN 标记计数
show queueing interface ethernet 1/1

# 看 PFC PAUSE 计数
show interface ethernet 1/1 priority-flow-control

# 看网卡侧
ethtool -S eth0 | grep -E "tx_pause|rx_pause"
mlxlink -d mlx5_0

第 2 步：基础配置（RoCE v2）

1
2
3
4
5
6
7
8
9
10
11
12
# 网卡侧（Mellanox / NVIDIA ConnectX）

# 启用 RoCE v2，DSCP 模式
mlxconfig -d <DEV> set ROCE_CC_PRIO_MASK_P1=0xff
mlxconfig -d <DEV> set CNP_DSCP_P1=48
mlxconfig -d <DEV> set CNP_802P_PRIO_P1=6
mlxconfig -d <DEV> set CNP_PRIO_MODE_P1=0

# 启用 ECN
mlnx_qos -i eth0 -f 0,0,0,1,0,0,0,0     # priority 3 用 PFC + ECN
echo 1 > /sys/class/net/eth0/ecn/roce_np/enable/3
echo 1 > /sys/class/net/eth0/ecn/roce_rp/enable/3

第 3 步：交换机侧配置

1
2
3
4
5
6
7
8
9
10
11
SONiC / Cumulus 上配置 PFC + ECN：
  - 选定优先级（通常 3）
  - DSCP → priority 映射（46/48/26）
  - 设置 PFC 阈值
  - 启用 ECN（WRED）
  - 调 buffer 大小

例：Tomahawk 5 64×800G
  per-port 入口 buffer：~12 MB
  PFC 阈值：~40-50%
  ECN_min / ECN_max：buffer 5% / 50%

第 4 步：监控

1
2
3
4
5
6
7
8
# 持续监测
watch -n 1 'mlnx_perf -i mlx5_0'

# 关键指标
- tx_packets / rx_packets
- tx_pause / rx_pause       # PFC 帧数（应较少）
- ecn_marked_packets        # ECN 标记数
- packet_drops              # 丢包数（应为 0）

“完全无损”是不存在的

万卡级 RoCE 集群很难做到”长期 0 丢包”：

1
2
3
4
5
6
7
8
9
10
现实：
  - 交换机故障：每天都有
  - PFC 调不到完美：偶发蔓延
  - 软件 bug：偶发包丢
  - 链路 flap：抖动期丢包

容忍策略：
  - 上层 RDMA 协议自带 RC 重传
  - NCCL 重连机制
  - 训练框架 checkpoint 恢复

追求 “PFC 帧 < 0.001%”，比追求 0 丢包更现实。

国产 AI 集群的实践

1
2
3
4
5
6
7
8
9
10
11
12
13
华为 Atlas + 鹊信：
  - 端到端控制（自家协议）
  - 比标准 RoCE 调优更彻底
  - 万卡级集群已成熟

腾讯 / 字节大集群：
  - 大量 SONiC + Tomahawk
  - 自研拥塞控制（HPCC 衍生）
  - 多团队全栈协作
  
阿里：
  - HPCC 算法发明者
  - Spectrum-X 也在试用

待补充：国产 AI 集群拥塞控制最新论文 / 公开数据。

几个权衡

graph TD
  Q1[网络规模]
  Q1 -- "<1000 卡" --> S1[默认 PFC + DCQCN 即可]
  Q1 -- "1000-10000 卡" --> S2[需要专门调优 1-3 月]
  Q1 -- ">10000 卡" --> S3[需要自研拥塞控制 / Spectrum-X]
1
2
3
4
5
PFC 多 → ECN 阈值太高
PFC 少 + ECN 多 → 调得好
PFC 少 + ECN 少 → 网络空闲

理想状态：     ECN 标记可观测，PFC PAUSE 接近 0

一些数字直觉

1
2
3
4
5
6
7
8
9
10
H100 万卡集群 RoCE：
  调通成本：    1-3 月 × 网络团队 5-10 人
  ECN 标记率：  正常 0.01-0.1%
  PFC PAUSE 率：希望 < 0.001%
  
故障类型分布：
  60%：链路抖动 / 光模块故障
  20%：PFC 配置不一致
  10%：拥塞控制振荡
  10%：其他（buffer 配置错等）

一个真实的”调优故事”

1
2
3
4
5
6
7
8
9
10
11
12
13
14
某万卡集群初期 NCCL AllReduce 30% 性能损失：
  分析：
    1. ECN 标记率正常
    2. PFC PAUSE 偶发但显著
    3. 单流性能 OK，全员训练时崩
  
  最终发现：
    a. 一台 leaf 交换机 PFC 阈值默认值偏高 → buffer 接近满才 PAUSE
    b. PAUSE 蔓延到上游 spine
    c. 全网吞吐崩
  
  解决：
    统一所有 leaf 阈值 → ECN_min/max 统一 → PFC 阈值统一
    AllReduce 性能恢复到接近 IB 水平

DCQCN 之外的下一代

1
2
3
4
5
6
7
8
9
10
11
2023+ 趋势：
  - INT-based（HPCC、Swift）：精确感知网络
  - In-Network Computing（SHARP）：减少 AllReduce 流量
  - Adaptive Routing（per-packet）：避免 hash 冲突
  - 闭源化：Spectrum-X 等"AI 网络栈"

NVIDIA Spectrum-X 提供"开箱即用"：
  - 默认 DCQCN 调优好
  - per-packet adaptive routing
  - PFC watchdog 内置
  - AI 流量识别 / 优先级

但所有”开箱即用”都需要全栈对接——网卡、交换机、NOS 都要 NVIDIA 的——锁定成本高。

小结

  • RoCE 在以太网上做”无损”靠 PFC + ECN + DCQCN 三件套
  • PFC 是链路级背压，急救但有 storm 风险
  • ECN 是端到端拥塞标记，配合 DCQCN 主动降速
  • 调优顺序：ECN 阈值优先，PFC 作为兜底
  • 万卡级集群拥塞控制是 1-3 月专项工作
  • NVIDIA Spectrum-X 提供”开箱即用 AI 以太网”
  • 国产路线：HPCC（INT-based）和华为鹊信（自研协议）

下一篇讲国产网卡和交换机——产业链全景。