PLB / PRR

主机 transport 层如何用 Flow Label 触发 ECMP 重路径

核心要点：

• host transport 通过修改 IPv6 Flow Label 触发交换机 ECMP 重哈希实现 repath
• PLB 用 ECN 信号处理拥塞，PRR 用 RTO/TLP/DSACK 信号处理故障
• 决策位置在 transport 层，纯软件改造（Linux 6.0+ 已合入）
• 故障恢复时间从 IGP 收敛的 > 10 s 降到 < 100 ms

PLB（Protective Load Balancing，SIGCOMM 2022）[1]和 PRR（Protective ReRoute，SIGCOMM 2023）[2]是 Google 提出的两个主机驱动路径切换方案：host 端检测到拥塞或路径故障时，通过修改 IPv6 Flow Label 触发交换机 ECMP 重哈希，把连接迁移到新路径——交换机不参与决策。相比 ECMP/AR 的交换机侧、DQPLB 的通信库侧、TE-CCL 的离线控制面，PLB/PRR 把决策完全下放到 transport 层。

为什么需要在 transport 层做 repath?

交换机侧路由的盲区

ECMP、AR 等交换机侧路由有两个根本盲区：

• 端到端拥塞信号交换机看不见：ECN 标记反映瓶颈链路状态，但只有发送/接收 host 能聚合"这条连接是否在受罪"
• 路径故障检测慢：链路故障后等待 IGP 收敛通常需要数秒到数十秒（取决于 BFD 间隔和 SPF 计算），期间该连接的所有报文继续走故障路径

PLB / PRR 的核心观察：host 已经从 transport 层（TCP ACK、ECN 反馈、RTT 测量）拿到了所有需要的信号，让 host 决定"要不要换路"远比让交换机决定快。

PLB / PRR 在路由方案中的位置

决策位置	代表方案	信号来源	反应时间
交换机 ASIC	ECMP	5 元组哈希	入口选定，不变
交换机 ASIC	AR	本地队列深度	μs 级
端点 NIC	Packet Spraying	无（统计均匀）	每包
通信库 host	DQPLB	CQE 反馈	segment 粒度
transport host	PLB / PRR	ECN / RTT / 故障检测	RTT 级
离线控制面	TE-CCL	拓扑 + α-β	编译时

@tbl-route-plb-decision-position 各路由方案的决策位置对比

PLB / PRR 的工程优势：纯软件改造——只改 Linux 内核 TCP 栈，不需要新交换机、新 NIC、新通信库。

PLB 怎么用 ECN 信号触发 repath?

整体设计

PLB 由两部分组成：

1. 拥塞检测：host 通过 transport 层信号（主要是 ECN 标记比例）判断当前连接是否拥塞
2. Repath 执行：在合适的时机修改 IPv6 Flow Label，触发交换机沿新路径转发

host                                  switch (沿用 ECMP)
──────────────────────────────        ─────────────────────────
TCP/RDMA transport
  └─ 监测 ECN 标记比例
       │
       ▼ 拥塞超过阈值
  PLB 决定 repath
       │
       ▼ 修改 IPv6 Flow Label
  下一个 TCP segment 用新 label 发出
                                      ───── switch ECMP 哈希
                                            (含 flow label) ─────►
                                            落到新桶 → 新路径

拥塞检测信号

PLB 使用 transport 层已有的 ECN（Explicit Congestion Notification）信号，不需要新协议：

• 接收方 NIC 把 ECN 标记报文统计到 ACK 字段
• 发送方 TCP 在每个 RTT 内统计 ECN 标记比例 $p_{\text{ecn}}$
• 当 $p_{\text{ecn}}$ 超过阈值（典型 50%）且持续多个 RTT 时，PLB 判定该连接拥塞

PLB 论文同时支持基于 RTT 抖动的拥塞检测作为补充信号——但 ECN 是主信号。

Repath 决策：Idle Period Repathing

PLB 的关键设计是 idle period repathing——只在连接进入"短暂空闲"时切换 path，目的是避免乱序：

$$\begin{equation} \text{repath if: } p_{\text{ecn}} > \theta \text{ AND idle\_gap} > \tau_{\text{gap}} \label{eq:route-plb-trigger} \end{equation}$$

其中：

• $\theta$：ECN 阈值（典型 50%）
• $\tau_{\text{gap}}$：连接连续两个 segment 之间的空闲间隔阈值（典型一个 RTT）

idle period 中已经在途的报文都已经 ACK，切换 path 后新报文走新路径不会与旧报文交错——这与 flowlet switching（见 04-自适应路由.md §逐 Flowlet AR）的乱序避免思路相同，但在 host transport 层而非交换机侧实现。

IPv6 Flow Label 重哈希机制

PLB 利用 IPv6 Flow Label 字段[3]（20 bit）作为 ECMP 哈希的额外输入：

• 标准 ECMP 哈希 5 元组（src/dst IP + src/dst port + proto），见 $\href{/interconnect/路由算法/ecmp}{\text{(3.1)}}$
• 支持 flow label 的交换机将其纳入哈希输入：

$$\begin{equation} \text{path\_index} = \text{hash}(\text{5-tuple}, \text{flow\_label}) \bmod N_{\text{paths}} \label{eq:route-plb-hash} \end{equation}$$

host 改变 flow label → 哈希值变 → 落到 ECMP 组的不同桶 → 走新物理路径。20 bit 的 flow label 提供 $2^{20}$ 种选择，足以保证新 flow label 大概率落到不同桶。

Linux 内核实现

PLB 已在 Linux mainline 内核合入（Linux 6.0+）[4]，通过 sk_rethink_txhash() 系统调用触发 socket 的 hash 重计算，新的 hash 用于生成新的 IPv6 flow label。配置参数：

sysctl	含义	典型值
tcp_plb_enabled	启用 PLB	1
tcp_plb_rehash_rounds	触发 repath 前等待的拥塞 RTT 数	12
tcp_plb_idle_rehash_rounds	idle period repath 的触发轮数	3
tcp_plb_suspend_rto_sec	repath 后多久内禁止再次 repath	60
tcp_plb_cong_thresh	ECN 标记比例阈值（128/256 = 50%）	128

@tbl-route-plb-linux-sysctl Linux PLB 配置参数

实测改进

PLB 论文披露的 Google 生产集群部署结果：

• 重负载 ToR uplink 的利用率不均衡度降低约 60%（论文主指标）
• 在 Spine 故障场景下，重度拥塞连接的尾部延迟和重传率显著下降
• 在生产环境中无需修改应用代码即可启用

PRR 怎么把故障恢复时间从秒级压到 100 ms?

PRR（Protective ReRoute，SIGCOMM 2023）是 PLB 的故障保护扩展，处理 PLB 不擅长的场景：链路完全失效而非"仅拥塞"。

与 PLB 的关系

维度	PLB	PRR
触发信号	ECN（"链路在用但拥塞"）	RTO 超时 / TLP / DSACK（"链路彻底坏了"）
反应时间	多个拥塞 RTT 累积	单次 RTO（毫秒级）
适用场景	容量退化、热点	链路硬故障、灰色故障
切换粒度	仅切换有拥塞反馈的连接	切换检测到故障的连接

@tbl-route-plb-vs-prr PLB 与 PRR 触发信号对比

二者协同部署：PLB 处理日常拥塞均衡，PRR 处理故障快速恢复。

端点故障检测

PRR 利用 transport 已有的故障信号，不需要新探测：

• RTO（Retransmission Timeout）：连续多个 segment 超时无 ACK，强烈暗示路径中断
• TLP（Tail Loss Probe）：尾包丢失探测，发现 trailing segment 丢失
• DSACK（Duplicate SACK）：接收方报告收到重复 segment，暗示某条路径异常

任一信号触发后，PRR 立即修改 flow label，把后续 segment 切换到不同路径——不等待 IGP 收敛。

与传统路由收敛的对比

阶段	传统 IGP 收敛	PRR
检测故障	BFD（数百 ms - 数秒）	RTO（毫秒级）
全网收敛	IGP SPF（数秒-数十秒）	不需要（host 自己换路）
受影响时间	总 RTO 期间所有报文丢失	单次 RTO 后切换
总停机时间	通常 > 10 秒	通常 < 100 ms

@tbl-route-plb-prr-vs-igp PRR 与传统 IGP 收敛对比

PRR 不取代 IGP——IGP 仍负责全局路由表更新——但 PRR 让"个别连接的故障恢复"不依赖于"全网都已经知道故障"。

Google Cloud 生产部署

PRR 在 Google 内部部署多年保护生产流量后，于 2025 年作为 Google Cloud 网络的默认特性对外公开发布[5]。论文披露的核心数据：

• 用户可见 outage 时间相比纯 IGP 方案缩短一个数量级以上
• 在多路径网络中（Google 全球骨干网典型 4-8 条并行路径），PRR 几乎可以掩盖单点故障

PLB / PRR 与 Bolt 拥塞控制如何协同？

Bolt[6]是 Google + Stanford 的 sub-RTT 拥塞控制算法，严格来说不是路由方案——它解决的是"以多快速度发"，PLB / PRR 解决的是"走哪条路"。但二者经常被一起部署，作为现代数据中心的协同栈。

各管一摊

方案	解决问题	控制信号	决策位置
PLB	路径选择（拥塞场景）	ECN	host transport
PRR	路径选择（故障场景）	RTO / TLP / DSACK	host transport
Bolt	发送速率调节	INT + programmable switch telemetry	host + switch
Swift	发送速率调节	RTT 测量	host
DCTCP	发送速率调节	ECN	host

@tbl-route-plb-bolt-stack PLB / PRR 与拥塞控制方案的分工

Bolt 的核心特点：sub-RTT 反应——传统拥塞控制需要至少 1 RTT 才能感知拥塞（信号绕一圈），Bolt 通过 programmable switch 主动报告 INT（In-band Network Telemetry）数据，让 host 在不到 1 RTT 内调整速率。其目标是 single-digit μs 级的 tail queuing。

协同部署典型组合

Google 数据中心的典型路由+CC 栈：

Application
   │
   ▼
TCP / transport
   ├─ Congestion control: Bolt（速率） or Swift（速率） or DCTCP（速率）
   └─ Repath: PLB（拥塞换路） + PRR（故障换路）
   │
   ▼
IP (flow label = repath 控制旋钮)
   │
   ▼
Switch ASIC: ECMP / WCMP（含 flow label 哈希）

PLB 改 flow label 控制走哪条路，Bolt 控制以多快速度发——二者正交。

PLB / PRR 与 ECMP / AR / DQPLB 的分工？

PLB / PRR 不取代 ECMP，而是构建在 ECMP 之上：

层级	机制	角色
交换机 ASIC	ECMP / WCMP	提供多路径基础设施（按 flow label 散列）
host transport	PLB / PRR	主动控制 flow label，绕开拥塞或故障
host transport	Bolt / Swift / DCTCP	调节发送速率

@tbl-route-plb-with-ecmp PLB / PRR 与 ECMP 的协同

关键点：PLB / PRR 不能在不支持 flow label 哈希的交换机上工作——需要交换机的 ECMP 配置把 IPv6 Flow Label 纳入哈希输入（多数现代 ASIC 默认支持）。

PLB / PRR 综合性能特性？

指标	PLB	PRR	AR per-flowlet（对照）
拥塞响应	有（ECN 触发）	无（仅故障）	有（队列深度）
故障响应时间	不专门优化	< 100 ms	秒级（依赖 IGP）
决策位置	host transport	host transport	交换机
硬件要求	仅 ECMP 支持 flow label 哈希	同 PLB	AR ASIC
部署复杂度	低（仅内核升级）	低（仅内核升级）	中（专用 ASIC）
乱序风险	低（idle period repath）	低（故障路径已停止发送）	低（flowlet 边界）

@tbl-route-plb-perf 性能特性对比

何时该用 PLB / PRR，何时不该？

适用场景：

• 已有 Fat-tree / Clos 多路径拓扑 + 现代支持 flow label 哈希的 ASIC
• 希望避免 AR ASIC 或 UEC NIC 等专用硬件投资
• 跨数据中心通信（cross-DC 链路故障+拥塞场景，PRR 尤其有效）
• 通用 TCP 应用（不需要 application 改造）

局限：

• 依赖支持 flow label 的 ASIC：老旧交换机的 ECMP 哈希不含 flow label，PLB 无效
• 响应时间在 RTT 级：sub-RTT 抖动需要 Bolt 这类拥塞控制协同
• idle period repath 在长连接持续发送时机会少：高负载训练场景下 segment 紧密相连时 PLB 无法找到合适 idle gap
• PRR 依赖 transport 自己的丢包检测：RDMA 类原生硬件 transport 需要 NIC 暴露相应信号
• 与 PLB 类似机制（IPv6 flow label）不能在纯 IPv4 网络部署

选型建议：

• IPv6 数据中心 + 现代 ASIC + 通用 TCP workload：PLB + PRR 是低成本最优选择
• IPv6 + AI 训练 RDMA：与 DQPLB 协同（DQPLB 管 QP 调度，PLB/PRR 管路径切换）
• 极致 sub-μs 尾延迟：PLB + Bolt 组合
• 纯 IPv4 网络：考虑 DQPLB 或 E-ECMP

Takeaway

知识点	核心结论
决策位置	host transport 层，仅 Linux 内核改造，无新硬件
触发机制	host 改 IPv6 Flow Label → ECMP 哈希落入不同桶 → 新物理路径
PLB 触发	$p_{\text{ecn}} > \theta$ 且 idle gap > $\tau_{\text{gap}}$（避免乱序）
PRR 触发	RTO / TLP / DSACK，故障检测毫秒级
vs IGP 收敛	故障停机从 > 10 s 降至 < 100 ms，不需全网收敛
协同栈	PLB/PRR（路径）+ Bolt/Swift/DCTCP（速率），正交工作
硬约束	需 ASIC 支持 Flow Label 哈希；纯 IPv4 网络无法部署

参考资料

1. Qureshi et al., PLB: Congestion Signals are Simple and Effective for Network Load Balancing, SIGCOMM 2022. https://dl.acm.org/doi/10.1145/3544216.3544226
2. Wetherall et al., Improving Network Availability with Protective ReRoute, SIGCOMM 2023. https://dl.acm.org/doi/10.1145/3603269.3604867
3. Amante et al., IPv6 Flow Label Specification, RFC 6437, 2011. https://www.rfc-editor.org/rfc/rfc6437
4. Add PLB functionality to TCP, LWN 2022. https://lwn.net/Articles/909957/
5. Google Cloud, How Protective ReRoute improves network resilience, 2025. https://cloud.google.com/blog/products/networking/how-protective-reroute-improves-network-resilience
6. Arslan et al., Bolt: Sub-RTT Congestion Control for Ultra-Low Latency, NSDI 2023. https://www.usenix.org/conference/nsdi23/presentation/arslan