这不是技术文档，这是技术以外的文档。
带宽资源越来越丰富时，大家反而不抢了，资源越稀缺争抢越厉害，相比丰盈的带宽，如今人们更关注时延。l4s 提供了完全不同的方案。但梳理一下传统方法是必要的。
30 多年来，人们将拥塞控制算法简单划分为 loss-based 和 delay-based，前者比如 reno，cubic，后者比如 vegas，无论哪一类都是以时延为代价控制拥塞，丢包作为拥塞信号时，重传时延是必须的代价，时延增加作为拥塞信号时，它本身就增加了时延，这种传统路子无论怎么折腾，无异于原地绕圈圈。
有个有趣的地方很多人都忽略了，vegas 自始至终从没有自称 delay-based，但将 diff = expected - actual 视为时延增加导致，将其归为 delay-based 就显得粗鲁。
如果 vegas 自身会导致时延增加，那一定因为它在不停增加 cwnd or pacing_rate，直到获得一个时延增加信号，然而 vegas 并没有主动增加 cwnd，它做的一切都在被动适应，理论上，时延增加一定是有新流进入，这是个指示当前所有流量出让部分带宽的信号，新流即使没有任何 probe 行为(实际上还有慢启动)，其它流出让的带宽也能被新流自然获取，反之，时延减少则是有流退出，需要均分它出让的带宽的信号。
vegas 采用与时延无关的方式对资源进行自适应，天然避免拥塞。vegas 只是用时延计算带宽，而起作用的是作为一个 “力矩” 的带宽时延乘积，它消去了参与计算的时延变量，是个表示实际拥塞作用效果(拥塞就要用 bdp 衡量)的量，可参考 vegas 的力学解释。
loss-based cc 固有的锯齿使针对它们的优化方案均旨在减小锯齿，从而获得带宽利用率的提升，而 vegas 理论上是无锯齿的。
如果网络是理想的，vegas 肯定是一个可伸缩的，公平的低时延算法，但网络不是理想的，因此 vegas 只能维持脆弱的不稳定平衡，而 aimd 则是稳定的平衡。不稳定平衡一旦偏离平衡点，正反馈将是灾难性的，这是它无法实用的根本。
l4s (的思想而非细节)为部署 vegas 带来了希望。
正如 aimd 需要类似 red aqm 提供支撑一样(否则将会跌入低效的全局同步)，vegas 为什么不能由另一个 aqm 支撑呢？只要利用 l4s 设施将传统流量隔离到单独的队列，甚至不需要它提供的 ecn 能力，vegas 自己就能适应。
l4s 的意义在于它为网络注入了真正的拥塞控制能力，它显式将拥塞信息第一时间直接通知到 sender，这是与传统的 aimd 完全不同，aimd 的 capacity-search 行为被认为是造成拥塞的原因而不是解决拥塞的方案，它解决的只是拥塞崩溃。
虽然 l4s 与 aimd 的思路完全不同，但 aimd 很容易被误解为拥塞控制的根基，以至于试图摆脱它只能是昙花一现的徒劳，参见 bbr 到 bbr3 的迭代。
基于 l4s 框架，tcp prague(一帮经理在布拉格开 l4s 副经理大会，提出了算法方案，延续 tcp cc 按照地名的命名法则，就叫 tcp prague，算法细节看参考 Prague Congestion Control) 延续了 dctcp，而后者也是一个 aimd 算法。
dctcp 本质上还是 capacity-search，它自己倾向于占满带宽和 buffer，其内核并不符合 l4s 的思想，l4s aqm 不断发送 ecn 修正 sender 先污染后治理的行为，与传统 red aqm 无大不同，而 vegas “保持 alpha 到 beta 个报文在 buffer 中” 则完全贴合 l4s 可扩展，低时延的理念，无论多少流量，在 buffer 中保持固定数量报文意味着时延不会随流量而变化，这便是可扩展性，而 l4s aqm 只需要确保在 buffer 中保持固定数量报文这件事的落地，修正 sender 的误估。
如此 l4s 岂不是只提供了个浅 buffer。话虽如此，但我们很容易想象一个 aimd 流在这个浅 buffer 中如何剧烈抖动，然而 vegas 在这个浅 buffer 中倾向于平稳而无锯齿，除非有流量进入或退出才会导致 vegas aiad，而为了防止 aimd 流量频繁干扰 vegas，l4s 还有一项任务就是将传统 aimd 流量(简单方法就是无 ecn capable，但也可用算法)隔离出去，这也是 l4s 框架的核心工作之一。
如果只提供一个截止闸，一套严酷的律法来治理环境污染，这种先污染后治理的方案显然不能真正治理污染，而将每家企业的碳排放维持在一个区间，这才是好的方案。惯常的 tcp 锯齿就是先污染后治理的形态，而 red aqm 钝化了这类锯齿，这是一种优化手段，但丢包仍是信号。而 l4s 既然可以提供显式信号，就取消了 aimd 的必要。剩下的公平性问题，只要大家遵守同一个规则就能保证公平性，类似上周我对 vegas 的分析那样，而 l4s 可确保这个规则得到遵守。
理想的端到端传输没有任何网络力量干预，aimd 在避免拥塞崩溃后通过 red aqm 提供了优化，这算是一种来自网络对端的干预，此后很难再看见，网络甚至会丢掉携带 ecn 的报文，人们笃信一定存在一种最优的端到端算法，于是人们拼命寻找它，然而信息量有限是个固有缺陷，该缺陷限定了端到端算法的上限，任何算法都在带宽和时延之间拧巴，vegas 稍好一点。突破极限还得需要网络提供更多信息，将 dcn 用了很久的 ecn 思路照搬到广域网，就是 l4s，它在长程传输中的作用力比 dcn 短程传输更大。
作为从 dcn 衍生的广域网 dctcp 版本 tcp prague 仅仅是个开始，vegas 固然不完备，但 dctcp 也并非真正的可伸缩，依然依赖启发式算法和处理技巧推动优化，在某个点上，它将不再可伸缩。但在数据中心内部，dctcp 本身可以做得更好，与 l4s 等效的 dcn 技术不胜枚举。
如果只是想了解一下 l4s，请看：Reduce network delays with L4S，如果要深入了解它，就看 rfc9330。
最后，不得不说，网络干预端实属一把不对称的双刃剑，在 dcn 实施的方案在广域网却不一定可行，因为在不受控的分布式环境，兼容性要考虑的更多，这也是最初把互联网设计成细腰型瘦网胖端模型的原因。拥塞崩溃固然可怕，它由指数传输量导致，但对网络设施本身牵一发而动全身的改造也是指数效应，更要慎重。
浙江温州皮鞋湿，下雨进水不会胖。