Google PLB(Protective Load Balancing) 简评

DCN 规则的拓扑(如 CLOS)给端到端带来多条等价 path，非常便于以 5-tuple hash 或 IPv6-Flow-Label hash 为 Key 利用 ECMP/WCMP 对 Flow 负载均衡。

但 ECMP 无法对应 Flow 和 Packet，这意味着它无法实时将一条拥塞的 big Flow 进行 re-path。若将 Flow 切为 Flowlet，则会造成 Flow 在 path 间 pingpong，在细时间粒度来看，依然不均衡。造成这种结果还是因为信息不足，交换机没有额外信息识别特定 Flow：

• 交换机对同一个 5-tuple 或 IPv6-Flow-Label 算出同一个 hash。
• 交换机有能力对所有 Flow 进行 rehash。

除非为 Flow 保持状态，当拥塞发生时，交换机可以找出排队最多 5-tuple 属于哪个 Flow，从而改变它的 seed，仅对该 5-tuple 进行 rehash，将它 re-path。

但这会增加交换机的复杂性和重新部署的成本，无论钱还是时间。

最近，Google 提出个简单有趣的方法：PLB: Congestion Signals are Simple and Effective for Network Load Balancing

• PLB 在 Host 解决问题：Host 通过 E2E 拥塞控制算法感知拥塞(RTT，ECN，Loss，or …)后更换 Flow 的 5-tuple 或 IPv6-Flow-Label，引导交换机 rehash。

无需解释就能体会 PLB 的妙处，它准备合入 Linux Kernel 6.2，如今 PLB 已经合入了 Google 的 BBRv2 分支：net-tcp_bbr: v2: add support for PLB in TCP and BBRv2

Host 感知拥塞需要足够的反馈，这需要足够的 round trips，而 DCN 内部的数据传输模式以短 message 为主，因此 PLB 仅针对占比少量的 big Flow 起作用，好消息是，占比少的 big Flow 贡献了占比大的流量，它们正是拥塞控制的实施对象。

遗留问题是，若 big Flow 数量小于收敛比，PLB 会造成 big Flow 在不同 path 跳跃，破坏公平性。正确做法是让 Flow 降 cwnd 或者分时调度 Flowlet，而不是直接 re-path，但单凭 PLB 很难识别该场景，re-path 只将当事 Flow 暂时带离拥塞，若该 Flow 不以足够强度反馈拥塞，新 path 将重新拥塞。

总之，big Flow 数量越多，PLB 对公平性改善越好。

网络负载均匀分布在等价 path 可提供最佳资源利用率，当某 path 发生拥塞，最坏情况是其它等价 path 空闲，PLB 有能力在感知到拥塞时对 Flow re-path(所谓 Congestion-Aware Approach)。虽然 PLB 并不知道哪条链路空闲，但最差也是破罐子破摔摆烂，如果运气好(大概率)，新 path 将更好。

PLB 的目标不是消除拥塞，而是将 Flow 均匀负载在等价 path，PLB 的算法(细节参考原始 paper 3.2 section)可以保证最终收敛到均匀，而这有利于 Host 端在更加公平的背景下实施 E2E 拥塞控制策略。

9 月份从 BBRv2 的最新进展中了解到 PLB，当时希望能在 IPv4 上 Backport 该功能，想到了修改 Flow 的 source port 来完成，这个在用户态协议栈双边实现很方便，对于修改 Kernel TCP，需要双边修改(主要是 4-tuple 唯一性判定，TCP Establish htable 的 rehash)，搞了一半，太麻烦。温州皮鞋老板昨天希望我介绍以下 PLB，就写了这篇。

浙江温州皮鞋湿，下雨进水不会胖。