L4S(低延迟低损耗可扩展) 的意义_dog250的博客-CSDN博客

接着 当 HTTP 抛弃 TCP 和 QUIC 继续。

可扩展的流：带宽 T，n 条流，每条流吞吐为 T/n，延时随 n 不变。

不可扩展流：带宽 T，n 条流，丢包与 n 正相关，延时抖动与 n 正相关。

从 1988 拥塞控制框架可以导出 TCP 的吞吐公式，据该公式可知，1988 框架下的流量都是不可扩展流量。

包括我自己在内很多人都曾经或正在纠结 TCP 为什么是锯齿波。绘制出一条 TCP 流的 cwnd/time 曲线，该曲线是个锯齿波，锯齿波形状随 cc 算法不同，但包括 BBR 在内，几乎所有 TCP 都是锯齿波。

TCP 锯齿波的本质成因是原教旨端到端原则。网络不反馈任何 “免费信息”，造成 TCP 应对信息时需支付代价，而代价带来的损失需要补偿后恢复。

有个专有名词描述 TCP 这类协议：Capacity-seeking protocol。下面是一段 Google 摘录：

Capacity-seeking protocols probe to find the maximum available throughput from sender to receiver, and, once they converge, attempt to keep sending traffic at this maximum rate. Achieving reliable low latency with capacity-seeking end-to-end methods is not yet entirely solved.

“探测-反馈-支付-探测” 环就是锯齿波本身。

端到端原则使 “端-网” 不沟通，“端-端” 不沟通，Capacity-seeking 就是必须，锯齿波就是必然。在控制论的数学角度，典型锯齿波表现为 AIMD 的结果。

我曾经说，AIMD 和 CSMA/CD 是一回事，前者是后者的零存整取版本，AIMD 相当于交换机替端侧积攒 “冲突”，提供无冲突假象，端侧得以执行 AI(Additive-Increase)，通过一次丢包将积累冲突反馈给端侧，端侧集中积累退避，即 MD(Multiplicative-Decrease)。

BBR，Vegas 也可理解为时延的零存整取，和 AIMD 不同的是，BBR，Vegas 冲突代价是时延增加，而非丢包。

像很多老式火灾告警装置一样，收到告警时火灾已经发生，该告警非常昂贵，并不免费。TCP 收到的 “非免费” 信号也一样，Reno/CUBIC 等 Loss-Based 流量检测到丢包后，buffer 已经 overflow，必须支付重传代价，同样地，Delay-Based Vegas，它 “观测到时延增长” 时，时延已经增长，而时延增长本身就是代价，同理，Timely，Swift 这种也一样。

为支撑 Capacity-seeking protocol，网络必须配备一定 buffer 并提供 AQM 来为端侧提供零存整取的 “丢包” 或 “排队延时增加” 信号，问题是 buffer 多大合适。

对每条流而言，buffer 大小与自身 RTT 相关，而每个瓶颈链路被所有流量共享，若 buffer 过浅，延时降低，但带宽利用率可能不足(MD 后会漏到 full-bw 之下)，若 buffer 过深，带宽利用率提高，但延时抖动也增加(AI 起始点时延差很大)。

无论对端侧还是对网络，目标是将锯齿变得既小又钝。但固定 buffer 大小无法适配 RTT 差异很大的所有流，对 RTT = 200ms 的流，10ms 排队延时微不足道，可对同一瓶颈链路 RTT = 5ms 的流，10ms 排队延时就是天价。

解决问题的方法倒也不难，根据 “频率 = 周期/秒”，按固定频率发信号即可。一个正确但不合理的 AQM，甄别出每条流，创建每流队列，拥塞时对每个队列的流量以一定频率进行丢包或者延时，提示端侧要降速是高尚的。

总结一下。端侧接收到来自网络的 “非免费反馈”(丢包 or 延时增加) 信号 ，这种反馈与一定大小的 buffer 相关，信号是积累的(零存整取)，端侧对反馈信号反应过激，造成锯齿波。

显然，为了不反应过激，需减少信号积累时间，变成零存零取，此即需要网络源源不断提供与流 RTT 解耦 “免费反馈”(or 至少相对便宜)，对于所有流量，反馈的应对压力应该是均等的。此即为道，此外皆术。

RFC9330，RFC9331，RFC9332 是 2023 年 1 月最新放出来的关于 L4S(Low Latency, Low Loss, and Scalable Throughput) 的 3 篇备忘录，详细描述了如何实施 “可扩展架构”。

上周五下班路上，我大致看了一下 RFC9330，发了一则朋友圈：

RFC9330 一个最新的标准，下午一个同事推给我的，大致看了一遍，一个创举！这个和我们去年的一个想法很像，主要就是在网络识别流量模式，注入奖惩模型，这样端系统就不敢乱搞了，至少可为 BBR 腾出一条干净的路。这个可以将流量收敛，避免拥塞，端系统什么都不需要做，继续作死，只要设备商跟进。设备商只要想卖设备，总能卖出去，暴力运营商让用户买单，简直复制了 Microsoft 和 Intel 的 wintel 环。而且对于拥塞控制，这在1988版之外开辟了一条真正的胖网新路，其意义远大于 BBR，我决定好好研究一下

所引用的 “一个想法” 是：

• 交换机专门开 3 个队列，记为Qr，Qa，Qp；
• 交换机对每一条流统计单位时间流量方差 Vi；
• 筛选方差接近 0 的流量集合放入 Qa，实施温和策略；
• 筛选出锯齿流量集合实施传统策略，如 wRED；
• 筛选出无法识别的大流量集合放入 Qp，实施惩罚策略；
• 3 个队列之间实施加权公平调度。

但它严重依赖流量识别算法的精度和包分类算法的效率，写论文 pr 可以，落地不现实，因此它只是一个想法。

L4S 依赖 ECT 就简单很多。L4S 将可扩展流量置于一个新队列，靠 ECN 源源不断送信号给 sender，避免了使用丢包信号(必须支付重传)或延时增加信号，这实在是个免费反馈信号。sender 根据持续收到的信号进行无级变速避免排队，从而确保低延时。

L4S 可确保低延时流量避开传统 TCP，否则只要有传统 TCP 流存在，要么损害全局公平性(若非 L4S，仅使能 ECN，确实会损害公平性，因为公平性是在所有拥塞控制算法之间检测的，而所有拥塞控制算法默认都是端到端的，网络从不提供任何免费信号)，要么抓破头兼容传统 TCP 友好，实现妥协，总之，根本无法确保低延时应用的体验。

现实中，L4S 对 BBR 影响深远。

BBR 在 1988 拥塞控制架构 之外提供了另一个视角，但它在 Google B4 bone 的部署依赖 SDN，这与公共互联网环境并相符。将 BBR 适配到公共互联网的过程非常难，好比说一辆好车找不到一条好路。

与大量 AIMD 锯齿波 TCP 混部，排队必不可少，BBR 非但没有能力确保低延时，还在不同 buffer 小大情况下表现出不同的有损行为，不得不妥协出 BBRv2。L4S 有能力甄别出 BBR 流量，无需和锯齿波 TCP 共存一个队列，也就不再需要 BBRv2，即 BBRv1 可持续迭代。若没有 L4S，BBR 最终将越来越 “Reno-like”，BBRv2，BBRv3，…

L4S 的意义在于在原教旨端到端原则之外，向网络倾斜了一些逻辑。既然是端到端原则，公平共存逻辑交给端侧就不合适，端侧只管根据信号平滑收敛，而网络主要负责两件事，一个是区分不同 cc 策略的流量到不同队列公平调度，二是为非锯齿可扩展流量提供反馈信号，将一次性反馈的积累信号平滑到连续的时间。

我比较看好 L4S 还有一点原因。它可以反卷。

现在的 CDN 厂商在 lastmile 的发送策略大多激进，敢激进是因为激进确实有收益让用户买单，95 计费又没太大成本，所以成交。大家都这么卷，所有 CDN 厂商的发送策略如出一辙，僵持竞速，谁也赢不了谁，工人工资成本反而是大头，招一个懂传输优化的工人非常昂贵。

有了 L4S 架构的动态 AQM 思路的指导下，激进行为在理论上就行不通了。

虽然目前还没有这方面的考虑，但下面想法的实现相信会有的。既然能甄别可扩展流量，也能甄别激进流量，专盯来自几家厂商源 IP(注册 IP 库很容易查询)，超额发 1 个单位丢 1.2 个单位。要么老老实实 AIMD，要么原生 BBR，想钻 1988 拥塞控制法不责众的空子，也就没门了，UDP FEC 的路子也一并堵死了。

L4S 的稍微阻力在部署，但也不很。

与原教旨端到端相反，依赖胖网(稍微胖一点)的拥塞控制对于 “惩罚” 是 “或” 关系，只要一跳节点给予惩罚，惩罚就拳打到肉了，但对于 “奖励” 却是 “与” 关系，所有节点均给予优待，奖励才能被授予，似乎惩罚更容易，奖励更难，但从博弈论视角看，要奖励并承担惩罚或不要奖励也不要惩罚，后者被选择概率更大，因此 L4S 可增量部署。

至于实现了新 RFC 的新设备，RFC9330 本身就是一个卖点(不管用到用不到)，只要设备商想卖设备，总能卖出去，运营商暴利，成本可转嫁，最终相当于用户买单，这只不过是另一个新的 wintel 环，就像 Intel 的新处理器总被 Microsoft 的新系统吃光一样，运营商买了设备，新特性很快被流量用起来，内容提供商和消费者都说好，付钱给运营商。公网部署一个新机制比数据中心要更容易推动。

…

当意识到 TCP 锯齿波时，人们想消除它，当意识这是 Capacity-seeking protocol 的属性行为后，人们接受它，作为实际部署的 Capacity-seeking protocol，TCP 是绝大多数网络拥塞问题的制造者，由于内秉 AIMD 行为，几乎所有想避开时延抖动的策略都束手无策，BBR 最终也妥协成了 BBRv2，但依然行走艰难。

问题的根源不是 TCP，不是 Capacity-seeking protocol，而是秉承原教旨端到端原则的执念。AQM 曾引起过争议，但不是它做得太多，而是做得不够。稍微让网络再多做点，如果 L4S 能普及，问题就变成了方法。

进一步思考端到端原则，极致原教旨端到端原则应该将计算逻辑继续往两端压，最终压到应用程序本身，连 TCP 也不再需要，应用程序直接 UDP-Based 做可靠传输或有损传输，这也是最近几年的驱使。可拥塞控制谁负责？

越 App-Spec，流量行为越缺乏共性指标，更难确保公平收敛，拥塞控制越倾向于往网络倾斜，这是一股相反的力量，好比当你往两边拉一条橡皮筋时，中间的橡皮筋被拉的越细，它将两边往中间收回的力越大。

举个城市规划的例子，到底是先造房子(端到端)还是先修路(胖网)？

筚路蓝缕的拓荒时期，先造房子有利于开拓，无论春秋时期，还是北美殖民者，或者闯关东，都先从点开始，最后才连点成面。互联网也正是端到端原则才在不到 30 年的时间迅速扩展，接入终端就像在空地上搭个棚子一样简单。这是对端到端原则的肯定。

另一方面，点状房屋越密，对道路要求越高，建房子的便利性收益被道路负载增加带来拥堵开销抵消，人们便倾向于吸取教训，开始道路规划，非机分离，修立交，修隧道，客货分流等措施优化交通。互联网也终于遭遇了这个问题，是时候优化 “道路” 了，这也是 RFC9330 的含义。

反过来，先修路正确吗？如上海五大新城，典型的临港路网，嘉定新城路网，地铁 11 号线一开始都是拖到荒无人烟的地方，然后再在路网格子空隙里造房子，若不是行政干预，相信没多少人自发搬过去。

要先有接入，后有传输。路是定居民走出来的，不是规划出来的。最终的形态，大概还是端到端原则促成，只是没那么原教旨，部分拥塞控制逻辑划给网络，这才是现实归宿。

看了 RFC9330，我觉得 TCP 有望摆脱锯齿波了，接着我又看了 RFC9331，RFC9332。这肯定是一个新路子。

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