摘要

  • RFC 9332 的 DualQ 框架以独立的 L4S 与 Classic 队列配合拥塞信号耦合。ECT(1) 以及特定情形下的 CE 是 L4S 标识，却不是实际入队、AQM 处理或排队时延的遥测记录。
  • 运营者可以在不改写端到端标识的前提下，把带 L4S 标识的包引向 Classic 队列；也可以把选定的非 L4S 流量放入 L 队列，而不把它改造成 L4S 流量。
  • Koen De Schepper、担任编辑的 Bob Briscoe 与 Greg White 共同完成的规范还列出了标识所不能代替的证据：逐队列流量、标记、丢包、平均时延、99 分位时延和过载事件。

包头只能陈述发送者的选择

设想监控系统在接入边界抓到一个包，看到 ECN 字段为 ECT(1)，随即在客户页面亮起“低时延”绿灯。抓包事实没有错，绿灯却跨过了两道尚未验证的边界。

ECT(1) 使理解 L4S 的网络节点能够识别发送者采用的实验性标识。它没有携带沿途分类规则、策略版本、队列编号、主动队列管理动作、停留时间或主导瓶颈。一枚两比特字段无法容纳旅程日志。它可以说明“这个端点按 L4S 规则提出处理意图”，不能说明“所有节点都这样处理过”，更不能说明“应用已经获得低时延”。

2023 年 1 月以 Experimental 类别发布的 RFC 9332 描述 Dual-Queue Coupled AQM：L 队列承载 L4S 处理，C 队列承载 Classic 流量，两边分别运行 AQM，再以耦合机制协调拥塞信号。调度器应优先服务 L，但优先权必须有界，不能让 C 饥饿。设计目标包括很低的排队时延、很低的拥塞丢包和可扩展吞吐量；目标仍需测量来证明。

标识不会因为本地拒绝而消失

RFC 9331 把 ECT(1) 以及适用语境中的 CE 定义为 L4S 标识。设置它的发送者理应采用符合 L4S 要求的拥塞控制。L4S 节点通常据此把包分到 L 队列。

“通常”不是疏漏，而是权责边界。RFC 9332 允许运营者因本地策略，把某些自称 L4S 的包排除出 L 队列。同时，它不允许节点仅因本地处理不同，就擦除或改写端到端标识。下游运营者仍应读到原始声明，并自行决定。

因此，一条准确记录可以是：观测到 ECT(1)；节点 X 命中策略 Y；进入 C；标识保持。发送者身份声明与运营者分类决定同时成立。强迫其中一项冒充另一项，反而损失证据。

反向情况同样存在。运营者可利用地址、Diffserv 码点或 DNS 等协议特征，把额外流量放入 L 队列，前提是不会损害服务。但节点不能因为给予了本地低时延处理，就把 Not-ECT 或 ECT(0) 改成 L4S 标识。进入 L 不能制造协议身份；携带 L4S 身份也不能证明每一跳都进入 L。两者之间不是一一对应关系。

DualQ 管理的是两种反馈行为

DualQ 不是给两条车道涂不同颜色。Classic 拥塞控制往往依赖一定排队量来充分利用链路；Scalable 控制可对频繁 ECN 信号作出幅度更小的速率调整。如果不加约束地混合，后者可能比 Reno 友好型流量激进得多。

设计于是把排队时延分开，同时耦合拥塞压力。RFC 的解释中，Classic AQM 产生一个基础概率；它的平方用于 Classic 的标记或丢弃，经缩放的版本则形成施加给 L4S 的耦合信号。L 队列从自身即时排队时延产生的原生信号与来自 C 的耦合信号中取较强者。

这说明 CE 标记不是时延样本。它可能来自 L 队列自身状态，可能来自 Classic 压力的耦合，也可能属于过载响应。它的职能是让端点调整，而不是报告某个包等待了多少微秒。

错配包更能暴露运行分支。ECT(1) 若进入 C，Classic AQM 应按耦合概率标记；ECT(0) 若进入 L，应兼顾 Classic 拥塞控制特性与 L 的时延目标；Not-ECT 位于 L 时，是否存在防范不响应流量的机制还会改变处理。单数 ECT(1) 数量，无法回答究竟执行了哪一支。

低时延从来不只有一只钟

即使获得了可信的 L 队列回执，也只证明用户体验的一部分。RFC 9332 对队列时延有明确边界：它不计队首包的序列化时间和介质接入时间，更不可能包含传播时延、其他节点的等待、传输层恢复、服务器调度与应用计算。

一个包可在某个 DualQ 中只等数微秒，整次请求却依然缓慢。反过来，一个 Classic 小包经过空队列时也可能很快，但它没有因此变成 L4S。队列时延、端到端 RTT 和应用响应时间必须分别记录。

均值也不够。RFC 要求实验实现应让运营者按队列、按采样区间导出平均与 99 分位排队时延，还可保留最大值用于诊断。低均值可能遮住少量严重长尾；没有时间窗的最大值会让一次旧故障永远悬挂。统计量、区间、分母和观测位置必须一起出现。

位置决定声明范围。在一处接入瓶颈部署 DualQ，可以解决重要的排队问题，却不能替另一个运营者、Wi-Fi 调度器、隧道出口或上游接口作证。“L4S 路径”涉及一串主体，不是某个设备能单方面签发的属性。

过载会改变系统能保住的东西

在常规且会响应拥塞的负载下，耦合机制试图让 L 保持浅队列，同时不饿死 C。意外流量与过载迫使系统重新权衡。L 的优先级必须有条件，否则持续繁忙的 L 可能短暂压住少量 Classic 包，包括 DNS 请求或初始窗口。

持续过载还有一道物理上限：ECN 标记达到 100% 后，再多一个标记也不能增强反馈。RFC 9332 要求能检测过载的 DualQ 实现，在事件消退前向两类 ECN 流量引入 Classic 式丢包；同时应报告过载的开始与持续时间，并用迟滞避免事件风暴。

一个 ECT(1) 包在过载前、中、后的标识可以完全相同，实际队列、丢包风险与等待却可能显著改变。可信状态页需要有时界的“过载中”记录，而不是永不过期的 L4S 徽章。

Bob Briscoe 的意义在于边界，而非英雄叙事

RFC 9332 的作者是 Koen De Schepper、Bob Briscoe 和 Greg White，Briscoe 同时担任编辑；致谢与贡献者名单还记录了更广泛的技术共同体。把成果讲成单一发明者故事不符合文献，也不能据此把任何运营网络的部署选择归于 Briscoe。

为本文留存的 IETF Datatracker 页面显示了他在拥塞控制、ECN 与传输研究中的长期文献记录；个人官网提供公开简介与肖像参考。这些来源证明人物和技术贡献，不证明当下市场份额，也不证明某家网络的实际表现。

这里真正有价值的是清楚的分界：端到端共享标识保持最小而稳定，本地运营者保留分类选择，实现方则要为标识无法承载的事实提供统计。这与 Heng Lu 的“最小初始规范”相呼应。运行代码优先原则补上证据顺序：RFC 与码点证明机制可用，真正执行的分支只能由运行现场证明。

代理问题出现在最便宜的事实获得最强的宣传语时。厂商容易展示 ECT(1) 计数；运营者导出分类器版本、逐队列计数与长尾时延的成本更高；用户承担服务风险。如果采购把“启用 L4S”当成低时延结果，掌握最少证据的一方反而取得最大解释权。

六张回执组成一条可审计链

第一张来自发送者：传输协议、拥塞控制实现与版本、设置 ECT(1) 的决定、流或会话边界与时间。第二张来自包边界：所见 ECN 字段、封装上下文、接口、方向、时间戳和抓包完整性。

第三张属于分类器：设备与软件版本、策略修订、命中规则、辅助标识和 L/C 结果。第四张属于队列：实际队列与 AQM 实例、入队出队观测、调度选择，以及错配组合调用的特殊分支。

第五张是拥塞回执：把原生与耦合压力连接到 CE 标记、ECN 与非 ECN 丢弃、过载进出时间，以及到达、提交 AQM、最终转发的包数。三种计数可区分队尾溢出与主动丢弃。

第六张是性能回执：逐队列记录利用率、均值、99 分位、可选最大值、采样区间与直方图定义。端到端 RTT 和应用响应使用各自的时钟与边界。六张回执没有否定 L4S 标识，而是让它只承担协议赋予的权威，不替未见事实作证。

来源