摘要

  • 验证成功说明发送的 ECN 标记与对端报告的 ACK_ECN 计数在一条路径上足够一致，可以用于拥塞反馈。
  • ECT(0)、ECT(1) 和 ECN-CE 是按 packet-number space 分开的累计计数，必须结合 ACK 历史解释。
  • 验证结果不识别队列、跳点、路由器、互联、运营者、持续时间、严重程度、SLA 违约或客户影响。

监控面板出现 ECN-CE 上升时，运营团队很容易立刻把责任归给某个互联。这个推断超出了协议证据。QUIC ECN 验证实际回答的是一个更窄的问题：在当前路径上，发送端能否把对端报告的标记当作拥塞反馈使用？它不是网络位置追踪器，也不是责任归属系统。

发送端可以把 IP 包标记为 ECT(0) 或 ECT(1)。网络节点可以把 ECN 字段改为 ECN-CE，以表示拥塞而不是丢弃数据包。能够读取 ECN 字段的接收端，会分别增加 ECT(0)、ECT(1) 和 ECN-CE 计数，并在后续 ACK 帧中报告。经过验证的路径出现新的 ECN-CE 增量后，RFC 9002 要求指定的 congestion controller 进入恢复。这说明协议如何反应，却不说明标记来自哪里。

累计记账的范围必须明确。QUIC 为每个 packet-number space 分别维护确认状态和 ECN 计数：Initial、Handshake 和 1-RTT。合并发送的 QUIC 包共享一个 IP 头，因此采用同一个 IP ECN 字段；但每个成功处理的 QUIC 包仍按自己的 packet-number space 计入相应计数。重复包不会再次处理，也不会重复增加计数。某个 ACK 报告的累计增加量，可能大于该 ACK 新确认的包数，因为较早的 ACK 可能已经丢失。因此，计数不是速率、跳点地图，也不是逐流的因果轨迹。

ECN 验证按路径独立进行。新连接、服务器首选地址变化以及主动迁移到新路径，都需要单独处理。端点可以在新路径上用 ECT(0) 标记早期数据包，然后将确认和丢失结果与报告的计数比较。如果新确认的 ECT 标记包没有 ECN 计数，验证失败；可能是某个网络元素清除了字段，也可能是对端没有报告。对于 ECT(0)，ECT(0) 增量与 ECN-CE 增量之和不能小于原本以 ECT(0) 发送而新近确认的包数；ECT(1) 适用同样规则。报告的计数也不能超过使用相应 codepoint 发送的包总数；从未使用的 codepoint 不应出现非零计数。没有推进最大确认包号的乱序 ACK，本身不应导致验证失败。

这些检查的是反馈是否可用，而不是反馈的身份。验证失败本身不能区分字段清除、错误改写、对端不报告、丢包、乱序、路径变化、恶意操纵或其他实现故障。失败时，端点必须在该路径上关闭 ECN，并停止设置 ECT，假定路径或对端不支持 ECN。之后可以重新验证；成功只允许继续标记，并不保证路径元素没有再次变化。

安全边界同样重要。丢包、延迟和 ECN 标记来自未认证的网络实体。攻击者可以丢包、改变路径延迟或改变 codepoint，从而影响发送速率。接收端也可能误报：压制 CE 可能使发送速率过高，额外报告 CE 则可能使发送端降低速率。验证和测试标记能检查反馈链的一部分，却不能认证某个队列、路由器、承载商、运营者或行政域。

证据账本应独立记录连接和当前路径身份、packet-number space、确认范围、每个包发送时的 ECT(0)、ECT(1) 或 Not-ECT、对端累计计数、相对上一个成功处理 ACK 的计数增量、验证状态转移、缺失计数、非法增加、标记包全丢、乱序和路径变化，以及 congestion controller 的反应和恢复周期。队列、接口、跳点、路由、互联遥测，以及运营者归属、根因、持续时间、严重程度和客户影响，必须另行记录。这个边界也区别于 TR-038 的 spin-bit RTT 采样、TR-045 的 ACK 交付语义、TR-050 的 ACK delay 和 TR-051 的 PTO 探测。