第 5 周：交换机队列、PFC、ECN、CNP 与 DCQCN
对应原计划：
plans/muxi-fabric-network-learning-plan.md第 5 周。
相关工程：plans/muxi-fabric-probe.md的 H5/H6 与 W3。
本章定位：学会区分“拥塞”这个笼统现象背后的不同机制：queue、shared buffer、PFC pause、ECN CE、CNP 和发送端 rate control。
0. 这一周到底学什么
第 4 周讲了 RoCEv2 packet 如何被分类到交换机 queue。第 5 周接着问：
如果 queue 真的拥塞了，网络和端点会发生什么？
RoCE 网络通常希望低丢包甚至近似 lossless，因此会使用 PFC 和 ECN/DCQCN 这类机制。但这些机制不是“打开就一定更快”，配置不当或流量形态不合适时，它们本身也会造成复杂性能问题。
学完你要能回答：
- egress queue、shared buffer、scheduler 分别在哪里起作用？
- PFC pause 是什么？它解决什么，又会制造什么问题？
- ECN CE 标记和 CNP 是什么关系？
- DCQCN 大致如何让发送端降速和恢复？
- pause 扩散、head-of-line blocking 为什么会影响无关流？
- 要证明 PFC/ECN/CNP 是根因，需要哪些 counter？
- 为什么只有端到端带宽下降，无法区分 PFC、ECN、ECMP、超分、接收端瓶颈和通信库问题？
本周核心原则：
“拥塞”不是一个机制。
必须说清楚：在哪里排队、触发了什么信号、谁响应、counter 是否对齐。1. 从 queue 开始：交换机为什么会排队
1.1 egress contention
最直观的排队发生在出口：
sender1 ┐
sender2 ├→ switch egress port → receiver
sender3 ┘如果三个 sender 各自以 200G 进入，但 egress port 只有 200G：
输入需求 = 600G
输出能力 = 200G多出来的数据只能：
排队；
被限速；
被 pause；
被 ECN 标记；
严重时丢包。1.2 shared buffer
交换机通常不是每个端口独占固定 buffer，而是多个端口/queue 共享 buffer 池。
这意味着：
一个热点 queue 吃掉 shared buffer；
其他 queue 即使不是热点，也可能受影响。1.3 scheduler
如果一个 egress port 有多个 queue，scheduler 决定谁先发：
queue 0: 普通流量
queue 3: RoCE
queue 6: 控制流量如果 QoS 映射错，RoCE 可能没有进入预期 queue。或者进入了正确 queue，但 scheduler 权重/优先级不合适。
2. PFC：按 priority 暂停上游
2.1 PFC 是什么
PFC = Priority Flow Control。它允许下游设备按 priority 暂停上游发送。
简化流程：
交换机某个 priority queue 快满
↓
向上游发送 PFC pause frame
↓
上游暂停该 priority 的发送
↓
下游 queue 消化后再恢复目标是避免丢包，尤其是 RoCE 对丢包敏感。
2.2 PFC 解决什么
它解决的是：
短时间拥塞时，不要直接丢 packet；
让上游先停一停，保护 lossless priority。2.3 PFC 会制造什么问题
pause 扩散
如果一个热点接收端让 leaf egress queue 满了，leaf 发 pause 给上游。上游被 pause 后自己的 queue 也可能涨，再继续 pause 更上游。
receiver 热点
↑
leaf pause
↑
spine pause
↑
其他 leaf 也受影响head-of-line blocking
PFC 按 priority 暂停，不一定只暂停那条造成拥塞的 flow。
同一个 priority 里的其他 flow 也会被影响：
flow A：真正打到热点
flow B：同 priority，但目的地不热点
PFC pause priority 3 → A 和 B 都停这就是为什么 PFC 问题可能表现成“看起来无关的 pair 也慢”。
2.4 小 case：PFC 误判
现象：
A→B incast 时，C→D 也慢可能是 PFC pause 扩散，也可能是：
ECMP 共享上行；
shared buffer 被吃掉；
背景流量；
C→D 本身路径变化；
通信库同步尾部。要支持 PFC，需要看到：
实验窗口内对应 priority 的 pause frame / pause duration 增加；
受影响端口和流量方向能对齐；
queue occupancy 达到 PFC threshold；
负对照没有同样 pause。3. ECN、CNP、DCQCN：标记和降速
3.1 ECN 是什么
ECN = Explicit Congestion Notification。
交换机发现 queue 超过阈值时，不一定丢包，而是在 IP header 里标记 CE：
queue occupancy > ECN threshold
↓
mark CE3.2 CNP 是什么
在 RoCE/DCQCN 语境里，拥塞信号会触发 CNP：Congestion Notification Packet。
简化流程：
packet 被交换机标 CE
↓
接收端/RNIC 看到拥塞标记
↓
向发送端发 CNP3.3 DCQCN 是什么
DCQCN 是 RoCE 的拥塞控制机制之一。发送端收到 CNP 后调整发送速率。
粗略理解：
CNP 多 → 说明拥塞严重 → 降速
CNP 少 → 慢慢恢复速率它像一个反馈控制环。
3.4 小 case：什么叫 ECN/DCQCN 闭环证据
比较强的证据链应该像这样：
实验开始
↓
某些 egress queue occupancy 上升
↓
CE counter 增加
↓
CNP counter 增加
↓
发送端 rate 降低 / pause 或 throttle 指标变化
↓
目标 flow 带宽下降
↓
实验结束后 counter 不再增长或恢复如果只有：
目标 flow 带宽下降证据太弱。
4. PFC 和 ECN 的区别
可以这样记：
PFC：让上游暂停，偏“别再发了，buffer 快满了”
ECN/CNP/DCQCN：给拥塞信号，偏“你发太快了，请调速”对比：
| 项 | PFC | ECN/CNP/DCQCN |
|---|---|---|
| 目标 | 避免丢包 | 提前降速，避免队列过深 |
| 信号 | pause frame | CE mark + CNP |
| 粒度 | priority/link | flow/发送端速率控制 |
| 风险 | pause 扩散、HOL blocking | 参数不当导致震荡或降速不足 |
| 证据 | pause counter/duration | CE/CNP/rate counter |
两者可能同时存在，也可能互相影响。
5. 和 Muxi incast 现象的关系
Muxi 看到：
7→1、15→1 incast 聚合入口约 24.2GB/s这和单个 200G 接收入口有效上限接近。
它支持：
单接收 rail/入口可能成为容量瓶颈；
多 sender 聚合时发生了入口方向的共享容量限制。但它不能证明：
PFC 触发；
ECN 触发；
CNP 导致发送端降速；
shared buffer 打满；
交换机物理超分；
ECMP 碰撞。要证明这些，需要网络侧 counter。
5.1 如果是 PFC，应该看到什么
接收方向相关端口/priority 的 pause frame 增加；
pause duration 和实验窗口对齐；
上游端口也可能出现 pause；
受影响流共享相同 priority。5.2 如果是 ECN/DCQCN，应该看到什么
queue occupancy 超过 ECN threshold；
CE mark 增加；
CNP 增加；
发送端 rate control 降速；
带宽曲线和 counter 时间对齐。5.3 如果只是接收入口上限，应该看到什么
接收端单 port bytes 接近 200G 有效上限；
不一定有 pause/CE/drop；
per-flow 公平分享；
换多 rail/多 GPU 接收时 aggregate 上限提高。6. 推荐阅读提炼
6.1 DCQCN
一句话
DCQCN 是 RoCE 数据中心里用 ECN/CNP 做拥塞控制的经典方案。
抓哪个问题
RoCE 为什么需要端到端拥塞控制？
交换机 CE 标记如何通过 CNP 反馈给发送端？
发送端如何降速和恢复？和 Muxi 的关系
如果怀疑 ECN/DCQCN，需要向沐曦/H3C 索取：
CE counter
CNP counter
DCQCN 参数
发送端 rate 状态
ECN threshold不能照搬
论文描述的是机制模型，xscale 的具体实现、counter 名字、默认参数必须以沐曦资料为准。
6.2 RDMA over Commodity Ethernet at Scale
一句话
这类材料说明大规模 RoCE 网络里，PFC、ECN、QoS、buffer 配置必须协同，否则会出现复杂问题。
抓哪个问题
为什么 lossless Ethernet 不是打开 PFC 就结束？
为什么 PFC 可能造成扩散？
为什么 ECN/PFC 阈值要和 buffer/headroom 配合？和 Muxi 的关系
它提供排查清单：不要只问“有没有 PFC”，而要问：
哪个 priority 开了 PFC？
headroom 多少？
threshold 多少？
实验窗口 pause duration 多少？
和流量方向是否对齐？6.3 Cumulus / RoCE QoS 文档
一句话
它给出实际配置链示例：priority、PFC、ECN、queue、buffer 如何组合。
不能照搬
命令和值不能照搬 H3C，但“必须拿到完整映射链和 counter”的思想可迁移。
7. 常见误判
- 带宽下降就是 PFC。
- 没丢包就没有拥塞。
- 有 PFC 就不会丢，也不会慢。
- 有 ECN 标记就说明发送端一定正确降速。
- CNP 增加就能解释所有慢。
- incast aggregate 接近 200G 就证明交换机拥塞。
- pause counter 增加就一定是目标流造成的，忽略背景流量。
- 只看端点带宽，不看时间窗内 counter。
8. 本周任务设计
8.1 任务 A：画拥塞反馈闭环
画出：
queue occupancy → PFC pause
queue occupancy → ECN CE → CNP → sender rate control并说明每个箭头需要什么 counter 支持。
8.2 任务 B：PFC vs ECN 辨析
给定现象：
incast 后目标 pair 带宽下降，其他 pair 也有尾部分别用 PFC、ECN、shared buffer、ECMP、通信库同步尾部解释一次，并写出区分证据。
8.3 任务 C：counter 请求清单
列出网络组需要提供：
per-port bytes
queue occupancy
PFC pause frames/duration
ECN CE marks
CNP counters
drop/retry
CRC/FEC并说明每项用于验证哪类机制。
9. 和 agent 讨论的问题模板
9.1 incast 机制拆解
请把这个 incast 实验按 PFC、ECN/CNP、shared buffer、ECMP、接收端 rail 瓶颈五类解释拆开。
每类列出支持证据、反证、还缺的 counter。9.2 counter 对齐
我拿到了实验窗口的 per-port bytes、pause、CE、CNP、drop counter。
请帮我按时间窗对齐，判断它们是否支持 PFC/ECN/DCQCN 机制闭环。9.3 最小网络侧请求
请帮我设计一个最小网络侧 ground truth 请求，要求能区分 PFC pause、ECN/CNP 和普通 egress queue 饱和。
每个字段说明用途。10. 本周最小掌握清单
- queue 是拥塞发生点：先问哪里排队。
- PFC 是暂停：保护 lossless，但可能扩散和 HOL blocking。
- ECN/CNP/DCQCN 是反馈降速：需要 CE、CNP、rate control 闭环。
- shared buffer 会造成非局部影响：热点流可能影响无关流。
- 带宽下降不是机制：必须拿 counter。
- incast 24GB/s 可能只是单入口上限：不能直接写 PFC/ECN。
11. 本周结束时你应该能解释的一段话
如果有人问：
“15→1 incast 聚合只有 24GB/s，是不是交换机 PFC/ECN 出问题？”
你应该能回答：
不能直接下这个结论。24GB/s 接近单 200G 接收入口有效上限，首先支持的是单入口容量瓶颈或聚合入口饱和。PFC、ECN/CNP、shared buffer、ECMP 碰撞、接收端 rail 映射、通信库同步尾部都可能产生类似带宽下降。要证明 PFC，需要 pause frame/duration 和 priority/端口方向对齐；要证明 ECN/DCQCN，需要 queue occupancy、CE、CNP、发送端 rate control 与实验时间窗对齐。没有这些 counter，只能把它们列为候选机制。12. 进阶时序：一次 incast 如何触发不同机制
假设 15 个 sender 同时打到 1 个 receiver：
s0 ┐
s1 ├──→ receiver
...
s14 ┘接收侧某个 egress 或 endpoint 入口容量接近 200G。15 个 sender 的总需求远大于 200G。
12.1 如果只是普通排队
时序可能是：
输入流量突增
↓
egress queue occupancy 上升
↓
scheduler 按队列服务
↓
per-flow 公平分享
↓
aggregate 接近 200Gcounter 可能显示：
per-port bytes 接近线速；
queue occupancy 上升；
没有明显 pause；
没有明显 CE/CNP；
没有 drop；这说明容量被用满，但不一定是 PFC/ECN 问题。
12.2 如果触发 PFC
时序可能是：
queue occupancy 接近 PFC threshold
↓
receiver 侧 leaf 发 pause
↓
上游端口暂停某 priority
↓
上游 queue 堆积
↓
其他共享该 priority 的 flow 也受影响counter 应该看到：
pause frame count 增加；
pause duration 增加；
priority 对齐；
方向对齐；
时间窗对齐；12.3 如果触发 ECN/DCQCN
时序可能是：
queue occupancy 超过 ECN threshold
↓
交换机 mark CE
↓
接收端/RNIC 产生 CNP
↓
发送端收到 CNP
↓
发送端 rate 降低
↓
带宽下降或稳定在某个水平counter 应该看到：
CE marks；
CNP sent/received；
sender rate control 状态；
queue occupancy 曲线；12.4 如果是 ECMP 碰撞
时序可能是：
多个大象流 hash 到同一 uplink
↓
该 uplink bytes 接近线速
↓
其他 uplink 空闲
↓
目标 pair 带宽下降counter 应该看到：
per-uplink bytes 不均；
改变 QP/flow salt 后结果变化；
pause/CE 不一定明显；12.5 结论
同一个 incast 带宽下降，可以对应完全不同机制。关键不是“有没有下降”，而是：
哪个 queue；
哪个 priority；
哪个端口；
哪个方向；
哪个时间窗；
哪个 counter；13. PFC 进一步拆解：为什么 lossless 也会慢
13.1 lossless 的目标
RoCE 对丢包敏感，所以网络常希望特定 priority 近似 lossless。
PFC 的目标是：
在 buffer 溢出前暂停上游，避免丢包。13.2 lossless 不等于 low latency
如果经常 pause：
没有丢包；
但发送端经常停；
队列持续堆积；
尾部变差；所以“没有 drop”不等于“网络健康”。
13.3 PFC storm / pause 扩散直觉
一个热点可以让 pause 往上游传播：
receiver egress 满
↓ pause
leaf 上游停
↓ queue 堆积
spine 方向受影响
↓ 更多 pause这可能让局部热点变成大范围抖动。
13.4 HOL blocking 直觉
同 priority 里的多个 flow 被一起暂停：
flow A：去热点 receiver
flow B：去正常 receiver如果 A 触发 pause，B 也可能被卡住，因为它们共享 priority/queue。
这就是为什么端到端 pair matrix 可能出现“块状一起慢”，但你仍不能直接命名物理拓扑。
14. ECN/DCQCN 进一步拆解：为什么标记不等于修复
14.1 ECN 标记只是第一步
交换机 mark CE，只说明：
这个 packet 经过某个超过 ECN threshold 的 queue。它不说明：
发送端已经降速；
降速幅度合适；
拥塞已经解决；14.2 CNP 是反馈
CNP 把拥塞信号反馈给发送端。
但还要问：
CNP 是否到达发送端？
发送端是否识别？
rate control 参数是什么？
降速后是否恢复过快？14.3 DCQCN 可能震荡
如果参数不合适，可能出现：
流量过冲 → CE/CNP → 大幅降速 → 恢复 → 再过冲表现为：
带宽周期性波动；
p99 高；
平均值不稳定；14.4 和 Muxi 的关系
如果 Muxi 只有端到端带宽曲线，没有 CE/CNP/rate counter，就不能区分：
DCQCN 震荡；
ECMP 碰撞；
PFC pause；
通信库同步尾部；
背景流量；15. 进阶辨析：drop、retry、FEC/CRC 与拥塞控制
15.1 drop
drop 是 packet 丢弃，可能来自 buffer 溢出、错误配置或其他原因。
RoCE 对 drop 敏感，因为重传和超时会显著影响尾部。
15.2 retry
RNIC retry 增加可能说明：
packet loss；
ACK timeout；
拥塞导致响应慢；
链路错误；但 retry 不是直接等于交换机拥塞，需要和 drop/ECN/PFC/FEC 对齐。
15.3 CRC/FEC
CRC/FEC/symbol error 更偏物理链路质量。
如果这些增加，说明可能有链路层错误，而不是普通队列拥塞。
15.4 小 case：带宽下降 + FEC 增加
如果实验窗口内：
某端口 FEC corrected/uncorrected 增加；
CRC 增加；
带宽下降；这更支持物理链路质量问题。
如果：
FEC/CRC 不变；
queue/CE/CNP 增加；更支持拥塞控制问题。
16. counter 对齐方法
16.1 为什么要对齐时间窗
只看累计 counter 很危险。
例如：
pause counter = 100000可能是历史累计，与当前实验无关。
要看：
实验前 counter；
实验后 counter；
delta；
时间窗是否覆盖实验；16.2 最小 counter 表
字段 用途
per-port bytes 看流量是否经过该端口，是否接近线速
queue occupancy 看是否排队
PFC pause frames 看是否触发 pause
pause duration 看 pause 影响时长
ECN CE marks 看是否做拥塞标记
CNP sent/received 看端点是否反馈拥塞
packet drop 看是否丢包
retry 看 RNIC 是否重传
CRC/FEC 看物理链路错误16.3 对齐方式
T0：实验前抓 counters
T1：开始实验，记录 run_id 和时间戳
T2：结束实验
T3：实验后抓 counters
Delta = T3 - T0最好还能有：
负对照时间窗；
空闲时间窗；
重复 run；16.4 小 case：pause counter 增加但不能说明目标流触发
如果 pause 增加，但同时有其他大流作业，不能直接归因到你的实验。
需要：
端口方向和目标流路径对齐；
时间窗精确；
无背景流量或有背景记录；
负对照不触发；17. 推荐阅读进一步拆解
17.1 读 DCQCN 时，重点看控制环
不要一开始陷入公式。先抓：
谁检测拥塞？
谁标记拥塞？
谁反馈 CNP？
发送端如何降速？
如何恢复？然后把它映射到 Muxi：
H3C switch 是否 mark CE？
xscale 是否生成/接收 CNP？
MCCL/RNIC 是否暴露 rate counter？17.2 读 RoCE at Scale 时，重点看“协同配置”
它告诉你：
PFC、ECN、buffer、QoS、routing 必须一起配置；
单独打开某个机制不代表网络健康；迁移到 Muxi 时，问题不是“有没有 PFC”，而是：
哪个 priority？
哪个 PG？
哪个 threshold？
哪个 headroom？
哪个 counter？17.3 读厂商 QoS 文档时，重点看字段链
你要提取：
DSCP/PCP 如何映射 priority；
priority 如何映射 queue；
PFC/ECN 在哪个 queue 上；
counter 怎么导出；不要直接照抄命令或阈值。
18. 本周自测题：带答案方向
18.1 PFC 和 ECN 的核心区别是什么？
答案方向：
PFC 是按 priority 暂停上游，目标是避免丢包；ECN 是拥塞标记，配合 CNP/DCQCN 让发送端调速。18.2 为什么没有 drop 仍然可能性能很差？
答案方向：
PFC 可以避免 drop 但造成 pause、排队和 HOL blocking；ECN/DCQCN 也可能降速或震荡。18.3 什么证据支持 PFC pause 扩散？
答案方向：
实验时间窗内多个相关上游端口/priority pause counter 和 pause duration 增加，并能和目标流路径、方向、负对照对齐。18.4 什么证据支持 ECN/DCQCN？
答案方向：
queue occupancy 上升、CE marks 增加、CNP sent/received 增加、发送端 rate control 降速，并和带宽下降时间窗对齐。18.5 incast aggregate 接近 200G 为什么不能证明 PFC？
答案方向：
它首先支持单接收入口容量上限。PFC 需要 pause counter/duration 和 priority/方向/时间窗对齐才能证明。