谁该来负责拥塞控制

寻找一种 host 公平而非 packet 公平的方法，有趣的是，CSMA/CD 网络就体现了这种方法。

端到端拥塞控制算法(cca)准不准先不论，仅说让它们运行，被控制的流至少要持续 2 个 RTT，一条持续传输的流是多数 cca 的约束。持续的流才能为 sender 带来自反馈信息作为 cca 输入以识别和控制拥塞。

可很多流量是 request/response 这种 one shot pingpong 类型，显然无法使用类似 cubic，bbr 等 cca 对其进行拥塞控制。

这种困境下，各公司的能人于是想出各类启发式算法，且这类算法还都是连接内闭环的，不屑依赖任何外部信息和历史信息，然后拿着这些算法参加大会，做讲座，写公众号，提派驰，不亦乐乎。这都是纯扯淡，不看历史，预测未来，可以预测地震了。

各类端到端 cca 本就是读史知未来，用一个 RTT 前的状态策划一个 RTT 后的策略，本身就有滞后性，对于 one shot pingpong 流量更是无历史可借鉴，只能说任何预测都是凭空的。

还要从最初去寻找根源，CSMA/CD 网络需要拥塞控制吗？它真不需要，就算 host 激进发送，最终只是本地 queue 溢出，影响不到别的 host。任何 host 在发送前都要侦听并在冲突时退避，这些对每一个 host 公平，而不仅仅对每一个 packet 公平。

CSMA/CD 天然携带 host 公平性，这种公平性由网络层面的载波监听和冲突退避来保证，而不是由端到端的传输层算法来保证。

在 交换以太网的诞生 这篇随笔中，我用一种逐步发展的方法描述了 CSMA/CD 总线网络到交换式网络的平滑过渡，最终一个总线上所有 host 的 CSMA/CD 的控制器(也就是实施载波监听，冲突退避的那个东西)变成了交换机，而交换机由交换网络和 buffer 组成。

那么由交换机保证公平性就合理了。交换机确实也是这么做的，比如支持各种公平队列调度算法，但交换机却不是无条件保证这些配置一定是正确的，比如对于 UDP 流量，交换机往往采用一种粗旷的方式。此外，交换机识别每一个 host 来确保公平并控制拥塞会带来巨大的单点性能开销并影响可用性，交换式网络的拓扑结构意味着它需要更上层的交换机无关的拥塞控制方案。

端到端拥塞控制是 1980 年代的一个创举，但它固有的 RTT 滞后性也必须接受，这种端到端方案需要从流自身提取拥塞信息，就需要流的连续性，也就是文初的描述，它无法作用于 one shot pingpong 流量。

要把连续流和 one shot pingpong 流纳入同一个拥塞控制体系，还得从 CSMA/CD 中吸取经验。既然载波监听和冲突退避从分布式的网卡集中到了交换机，让交换机负责拥塞控制就是高尚的。

CSMA/CD 网络中 host 的本地溢出正好对应交换网络中交换机发出的源抑制报文，虽然源抑制报文的传播时延不可消除，但至少无需等满一个整 RTT 才能获得拥塞信息：

源抑制的方案和问题在 RFC 896 提到，彼时是一个端到端拥塞控制方案尚未被引入的干净时期，但现在却是端到端方案也出现了问题的浑浊时期，至少在数据中心，源抑制的思想早就落地，PFC，INT-Based cc 均是源抑制思想的体现，就像 CSMA/CD 反压本地 host，反压上一跳是一个意思。

想更高效精准进行拥塞控制，离不开交换机(包括一切转发节点)的协助，包括不限于公平队列，L4S，发送源抑制，甚至可以提前预测拥塞并广播。不要总被互联网瘦网胖端的模型冲昏头脑，也不要总以 “我们动不了交换机” 而执着于闭环端到端方案，闭环端到端方案的上限大概就在 cubic 和 bbrv1 中间的某个点。交换机明明是拥塞的目击者，却偏偏将其排除在事外，这是不高尚的。

但个中原因也并非不可理解，这又是程序员和网工之间反射出来的端和网之间的本质差异，程序员守着 host，当然看不到网络的细节，也就想在端到端闭环了。

幸运的是，数据中心网络已经越来越多将邀请交换机一起进行拥塞控制，而对于广域网，也有了 L4S 等方法，CDN 和 SDWAN 的部署事实上将用户相关的广域网局限在 lastlime，而随着带宽的增加和直播的发展，配合良好的编解码技术，永不拥塞的 application-limited 流量将越来越占主导地位。

如此背景下，拥塞控制确实要换一个思路，将避免拥塞崩溃为目标过渡到以提高带宽利用率为目标，bbr 已经在 2016 年走上了新路，但即便 bbr 也依赖一条持续足够久的长流。

皮鞋没有蹬上，露着白袜子。

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