PLB: Congestion Signals are Simple and Effective for Network Load Balancing读后思考

这周我读的论文是PLB: Congestion Signals are Simple and Effective for Network Load Balancing。这篇论文是谷歌提出的一个建立在传输层协议和ECMP/WCMP基础上的以减少网络中热点区域（即很多流都通行的区域）的保护性负载平衡设计方案PLB。PLB随机地改变遇到拥塞的连接的路径，倾向于在空闲时间后重新路径，以减少包的重新排序。它通过改变报文上的IPv6流标签(交换机包括ECMP/WCMP的一部分)来重新引导连接，并降低RPC的延迟。PLB在谷歌中经过部署和实验，也取得了良好的效果：谷歌数据中心中高负载ToR上行链路的中位利用率不平衡下降了60%，包丢弃相应下降了33%，小型rpc的尾延迟(99p)下降了20%。

现代网络通常使用Clos拓扑来扩展容量，这种设计导致从一个源到每个目的地的路由有许多路径，跨可用网络路径分配负载的有效机制对于应用程序性能和网络效率至关重要。常见的负载平衡机制就是ECMP和WCMP，然而二者均不能产生平衡的负载，甚至可能会加剧网络热点区域的拥堵。然而目前的很多替代涉及会给网络增加很大的复杂性，导致成本增加，可靠性风险增加，发展缓慢。因而PLB被提出来，因为其仅仅利用IPv6标签就能清晰地分离路径和连接多路复用的角色，且容易部署以及向后兼容。PLB是建立在FlowBender的早期工作的基础上，他使用IPv6流量标签来重新进行路由连接，交换机只是在通常的四元组上加上流标签，转发带有ECMP/WCMP流哈希的IPv6报文;现代交换机硬件支持这种配置。它允许主机在可用路径集中随机更改流的路径，而不需要应用程序参与。FlowBender只是在遇到拥塞时移动连接，而PLB更倾向于在空闲时间后重新路径，以减少由于包重新排序造成的传输交互。这种策略使得小型RPC在热点区域处比大型RPC更频繁地重路径，从而导致较低的尾部延迟。

由于ECMP/WCMP忽略了流量大小，且数据中心的工作负载是重尾的：大多数字节都是在一小部分RPC中传输的，只有一小部分流量会影响负载，现有工作并不能实现真正的平衡的负载，为了测量不平衡性，论文将负载不平衡性(LI)定义为每个ToR上行链路(指向数据中心核心交换机)的最大-最小利用率（超过30秒）。PLB要解决如何将流分配到可用的路径上，使热点处的网络流量最小化，但是它并不要求在所有位置上平衡链路利用率，只要求在拥塞点上平衡链路利用率，这是因为PLB的最终目标是提高应用程序的性能。

因此，PLB的设计包括两个部分:拥塞检测和改道。发送端主机通过传输检测到连接正在经历拥塞。然后，它通过为后续的出包分配一个新的、随机生成的流标签来重新引导连接。这个动作的效果是选择碰撞的流形成热点流，并概率地将它们通过可用路径分散开来，根据需要重复以减少哈希冲突。PLB并不需要额外的拥塞检测方式，仅仅采用现有的拥塞控制算法中的拥塞信号。论文还分别将其部署在TCP和Pony Express上进行测试。

无论是部署在TCP还是部署在Pony Express上，PLB都需要完成以下功能：

1. 检测拥塞。PLB-TCP发送方使用一个简单的DCTCPlike启发式[5]来检测连接是否拥塞，当队列超过某个阈值时，交换机在数据包上标记CE。接收端向发送端回CE标记。对于接收到的每个ACK，发送方计算每次往返带有CE标记的包的百分比。当这个分数大于常数K时，就任务这一轮是拥塞的。在经历了M轮连续的阻塞之后，就将流标记为阻塞。只有在连续轮阻塞时，流才保持阻塞。具体的参数建议值论文也有介绍，这里我不再赘述。
2. 用最小的重新排序代价进行重新路径规划。如果PLB天真地将流从高队列的较长路径移动到较短的路径时，这可能导致数据包在接收端重新排序。并且，当收到的报文无序时，通用接收卸载(GRO)聚合会提前结束。这对发送方和接收方都造成了很高的CPU损耗。为了避免重新排序，PLB试图推迟对拥塞流的重新路径，直到流变为空闲状态。
3. 将小型rpc从繁重的流中移开。因为数据中心流量是重尾的，占流量大部分的大流量会导致严重的排队，从而影响小型rpc的延迟。由于发送小型rpc的连接经常处于空闲状态，PLB倾向于方便地将它们移出由大流量或大型rpc组成的大队列的路径。
4. 处理链路故障。当发生链路故障时，小型传输(例如单包rpc)很容易受到攻击，因为它们只有很少的ack来返回CE标记，但这是会发生超时重传RTO，PLB会重新规划路径使得链路故障得以解决。

这篇论文通过在在我们的TCP和Pony Express、ToR、spine和wan边界交换机的实验结果表明，PLB不仅能减少交换机链路负载不平衡，还能减少交换机数据包丢失。PLB还可以降低应用程序RPC尾部延迟，并通过重新路径引起微不足道的传输CPU或重传输惩罚。在有拥堵热点区域的情况下，它是非常有效的。但是关于如何与WCMP交互、如何应对应对链路故障以及如何与非PLB流共存这几个问题，我还有较多不理解的地方。