再看一遍最传统 TCP AIMD 吞吐的推导：
这个积分用离散求和表示很简单，一个锯齿发送的报文总数为：
( W 2 + 0 ) + ( W 2 + 1 ) + ( W 2 + 2 ) + . . . ( W 2 + ( W − W 2 ) ) ≈ 3 ⋅ W 2 8 (\dfrac{W}{2}+0)+(\dfrac{W}{2}+1)+(\dfrac{W}{2}+2)+...(\dfrac{W}{2}+(W-\dfrac{W}{2}))\approx\dfrac{3\cdot W^2}{8} (2W+0)+(2W+1)+(2W+2)+...(2W+(W−2W))≈83⋅W2
一个锯齿丢一个报文，求丢包率：
p = 1 3 ⋅ W 2 8 = 8 3 ⋅ W 2 p=\dfrac{1}{\dfrac{3\cdot W^2}{8}}=\dfrac{8}{3\cdot W^2} p=83⋅W21=3⋅W28
设往返时间为 T，一个锯齿的时间为：
D = T ⋅ W 2 D=T\cdot\dfrac{W}{2} D=T⋅2W
假设一个包中的数据量为 K，则吞吐量 R 为：
R = 3 K W 2 8 D = 3 K W 4 T R=\dfrac{3KW^2}{8D}=\dfrac{3KW}{4T} R=8D3KW2=4T3KW
将 p 代入，得：
R = 1.25 K T p R=\dfrac{1.25K}{T\sqrt{p}} R=Tp 1.25K
这就是最传统的 TCP 吞吐公式。
只要你的传输协议理论吞吐(T 一样)比它大，你的协议就很难被标准华文档(BBR 持续停留在 Draft 阶段很大程度因为此)接纳，更严重的是，这个公式是脆弱的，不保真的。此话怎讲？
上述公式是没有任何噪声丢包和链路误码丢包的前提下推导出的 TCP 最高吞吐率，即丢包完全由 buffer overflow 导致。然而实际链路难免会出现误码丢包，因此该公式是要打折扣的：
R = 1.25 K T p + p N R=\dfrac{1.25K}{T\sqrt{p+p_N}} R=Tp+pN 1.25K
其中 pN 为噪声丢包率，链路越长，噪声丢包概率越大。对应到上面的图示，假设范雅各布森管道中 buffer_size = BDP，如果加上与 p 相等的 pN，相当于 buffer_size 减半了，即明明是一个 deep buffer 链路，由于出现过大的噪声丢包，大量的 buffer 是无用的，对 TCP 而言等效于一个 shallow buffer 链路。
由于现实中存在大量多年前部署的 "传统 TCP 服务"，因此去抢占这些倚老卖老的旧服务的带宽是不光彩的，也是不讨好的，除非说服它们升级到一个对新事物更加公平的支撑平台，比如 5.4 以上的内核 + BBR/Quic。
另一方面，提高物理链路的可靠性是一劳永逸的，最大限度降低噪声丢包率，尽量给传统 TCP 这些脆弱的老家伙们舒适的环境，使它们的吞吐无限接近上述公式里没有 pN 的 R，但在这些老家伙身上再动大手术是不合适的，比如优化 CUBIC。
下层对上层提供服务本就是协议栈所以为栈的一部分内容，提供优质服务更是逐渐成为刚需。因此不要再将 "TCP 在劣质链路提供可靠服务" 的假设作为上限，而是反过来督促底层链路的优化。"能用就行" 在早期筚路蓝缕，以启山林，但如今的这种假设不再合适。
从广域网说到数据中心，在这里发生着一件类似的事情，指望 PFC 提供无损网络类似于 TCP 之于劣质长肥管道，Pause 帧是一种兜底，但不能用于优化，就像 AIMD 不能用于优化传输吞吐一样。如果本末倒置，事情就会变得越来越复杂。
扩容，增加带宽，优化收敛比就能解决大部分问题，非要引入 PFC，随着端网卡带宽增加，BDP 增加，PFC 所需的 buffer 持续增加，时延以及时延抖动持续增加，此外，PFC 解决不了链路误码丢包问题，最终还是要端主机 GBN 兜底。
在数据中心传输优化这条路上，特斯拉的 TTPoE 显然是正确的，因为它先天假设了一条非常良好的底层链路，因此它不断最减法，不断简化，就像当年 TCP 假设了一条非常恶劣的底层链路，只能不断做加法，不断复杂化的反面一样。
昨天的文章里说了一句话，大自然是和谐的，当一件事变得越来越复杂时，大概率就是路线错了，如果一个结论不美不封闭，可能就是来自错误的路线。我跟八年级女儿讲，在解一道数学题时，如果中间步骤出现了丑陋繁杂胶着的无理数运算，几乎就已经错了，这是一个真理。
浙江温州皮鞋湿，下雨进水不会胖。