PFC(Priority-based Flow Control) 的 100 种优化方法

简单直接的东西不需要优化，只有弄巧成拙的东西才不断被修补，优化，没完没了。

昨天聊 RDMA 和无损网络，我还是一如既往喷 PFC，并提出一些等价想法，被怼异想天开。随后我换了群昵称和头像，若干分钟后，我再一次提出相同的观点和方案，但换了个说法，学着 YaPFC(yet another)，PFC-ng，PFCPro，PFC++ 的样子，比如前向 PFC，后向松散 PFC，本地 PFC 等等，马上就有人问论文出处了。

看，这里有大生意，把想法包装一下，往时髦概念上靠，一个点就能水一篇论文，“具有 yy 特色的 xx”，其中 yy 是新想法，xx 是时髦具有共识的东西，号称打着 xx 的旗号 yy 。

以上整理自昨天发的一个朋友圈，今天整理成文。本文提出的方法单独揪住一个讨论，能找出 100 个不合理的细节，每一个不合理的点都能再水一篇改进论文，更一般的，随便找一个人都能说出 100 个类似的方法，但并不是每个人都有能力拿来变现，无论是卷钱还是卷名声。

PFC 的核心是通过一种流控算法提供一个拥塞后不丢包的网络。相比于拥塞后 buffer 自然溢出而丢包，使其不丢包的方法有很多种：

• 向前抑制拥塞流量
• 向后疏导拥塞流量
• 本地存储拥塞流量

一般意义的 PFC 就是第 1 种。之所以这种方式最简单，源自于以太网固有的 pause 帧，稍加改动，针对队列 pause，而不是针对端口 pause，就是 PFC，好处是缓解了 HoL，但由于队列数量有限(8 个)，仍会有受害流卷入拥塞树蔓延，死锁等问题。

针对这些(遗留?)问题，每一种解法就是潜在的一篇论文：

• 如何缓解拥塞树的蔓延，将其限制在一定范围；
• 如何缓解或彻底解决对受害流的时延伤害；
• 如何缓解拥塞被 pause 期间的时延不确定性；
• …

PFC 因向前抑制导致了问题，问题的解法大概方向就是 “向前抑制的细节”，“向后疏导” 和 “本地疏导” 了。

为抑制拥塞树蔓延导致的死锁，PFC 可以设置一个坚持时间，在坚持时间到期仍没有缓解拥塞，考虑到 sender 有 GBN 兜底，用越来越强的丢包丢弃报文就是合理的，在此之前，向前的 pause 强度逐渐降低亦可缓解拥塞树蔓延。

此外，控制 pause 帧蔓延固定跳数也可缓解，由于抑制分担有限，为确保不丢包需要额外大量复杂工作疏导拥塞流量，在本该丢包的网络不丢包是一件拧巴事，拧巴事大概率不正确，无论怎么向前抑制。

另一种合理的方法与向前抑制相反，向后疏导，剩下的交给路由也是高尚的：

这也是大禹治水的方法，疏导而不是阻塞。

下一个方法，不那么激进，对传统 PFC 的修改很小。交换机持续观测队列变化，在尚未发生拥塞但触发某种预警时预判，提前触发 pause 帧，在更长的时间平滑控制队列长度，以此缓解 PFC 造成的时延增加和抖动。

再看另一种更直接和接近本质的方法。

大 buffer 可以在 ECN 被 sender 感知并做出收敛反应前缓存本该被丢失的报文，但不为每个交换机端口输出队列配置大 buffer 的原因有二，capacity-seeking 协议(如 TCP，RDMA) 会用尽无论多大 buffer，付出平均大时延代价，此外，大 buffer 不便宜。

解决 capacity-seeking 协议贪吃 buffer 问题的方法是触发使用 buffer，在预判拥塞发生时才动用后备大 buffer，而解决价格问题的方法则是用高速存储技术替代内存 buffer，比如 SSD，NVMe。

用一块高速大硬盘(稍慢，但便宜)本地存储拥塞流就是自然而然的。配合持续流分类算法(参见 自适应拥塞控制 AQM，隔离长短流，核心是采用一系列多维分类算法)精确分拣拥塞流进入后备大 buffer，这同时避免了受害流，拥塞树扩散以及死锁问题。

就像 Kafka 存储没取走的消息一样，从 Kafka 中看到同样的设计，作为一个可靠的消息队列系统，Kafka 需要确保消息不会丢失。通过将消息存储在本地，在遇到如网络故障、拥塞等，消息仍能够安全地保存在磁盘上。

简单可行吧，但话不能这么说，得编一个包含 PFC 的名字，比如 Local-PFC，管不管用先不说，但做论文素材足够了。

不多说了，类似方法随便找个人都能说出 100 个，遣词造句，字里行间不含 PFC 的一文不值，包含了 PFC 就是大佬牛逼。

一开始 PFC 就错了，在数据中心丢包恢复相比坚持住不丢包是一件容易的多的事，且没有副作用，无损网络本身就是个伪需求，过载拥塞感知能力太弱同时是原因和结果。拥塞了丢包重传，拥塞了不丢包，从时延的观点看完全等价，重传时延等于 pause 时延，从能耗观点看亦等价，重传能耗在端，PFC 将能耗转移到了交换机。

时延，能耗，最终都是钱，总是要花代价的，问题的本质是拥塞，但拥塞本身也是一个非常良好的收敛信号，却被 PFC 淹没了。

无论如何，端到端低时延和高吞吐不可兼得，问题是通过一个算法可以解决的吗？是带宽不够啊。举个喝酒的例子(我自己的例子)，发烧时我发现自己酒量剧增，怎么喝都不头晕，但这只是假象。高烧导致神经系统被抑制了，淹没了酒精的信号，喝酒时头不晕阻止不了第二天难受，且由于忽略信号喝得更多，比平时喝醉更难受。

PFC 的设计者和拥护者不懂什么叫交易，兑换，兑付，没收益的行为也有代价，出来混早晚要还的。

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