Summary

  • STAMP CoS ECN 草案第 02 版在原有 EC2 去程观察字段之外，增加 EC1 指定回程包的 ECN 值，并用 RPE 回报反射端是否照办。
  • 反射端成功设置请求值时写 RPE=0b11；不能设置而改用零时写 0b10。只支持 RFC 8972 的旧反射端将新位当作保留位，回 0b00，不能据此声称已测到回程 ECN 行为。
  • 发起方若在一个往返时延内发出多个带 ECT 标记的探针，就必须观察 CE 拥塞标记，并有能力降低去程发包或由它诱发的回程流量。

一台监测设备每秒发一两个包，像拿温度计量水温。把采样频率推高，温度计就变成了加热器。STAMP 的发起方送出测试包，反射端回包；这套往返可以揭示路径特征，也会占用同一条路径的容量。RFC 8762定义了这两个角色，而 RFC 8972给测试包加了服务等级字段，让反射端把收到的 ECN 值放进 EC2。发起方于是知道包抵达远端时的标记。

问题在回程。原有字段不能独立要求反射端把某个 ECN 值写进回包的 IP 头。回来的包没有 CE，可能是路上没有拥塞，也可能是反射端根本没发出一个可被 ECN 标记的包。11 月 2 日草案借用旧格式的保留位：EC1写发起方期望的回程值；RPE写反射端采取了什么动作。远端能按请求设置，就回 0b11。受本地策略或平台限制，无法设置而用 0b00，就回 0b10。发起方再看实际收到的 IP 头，才能把“要求过”“远端照做了”“沿途发生了什么”分开。

这也是兼容旧设备的方法。只懂 RFC 8972 的反射端把 EC1 和 RPE 当保留位，返回的 RPE 仍为 0b00。此时没有回程测试能力；它的沉默不能冒充链路健康报告。新设备也可能拒绝指定 ECN 值，0b10 会把这件事明说。草案给了测量者一个小而重要的诚实字段：先证明测试条件成立，再解释测试结果。

最硬的一段在发包速率。草案规定，发起方若在一个 RTT 内发出多个去程 ECT(0) 或 ECT(1) 测试包，必须读取回包 EC2，见到 CE 时有能力降低发送速度。若它通过 EC1 要求回程包带 ECT 标记，也必须观察回包 IP 头中的 CE，并有能力降低由自己请求产生的回包速率。一个测试包若还能要求多个反射包，发起方要能调整后续请求参数。反射端按要求回答，负载却主要由发起方的测试计划控制。

草案不替实现者写具体降速算法；它把拥塞响应接到 RFC 3168 和 RFC 9330的规则上。对运营者而言，仪表盘上的“检测到拥塞”还差半张回执：探针随后发了多少包？反射端被它诱发了多少回包？速率是否下降？数据可以很漂亮，队列却要替它付账。

草案允许一类有边界的例外：为了测量过载时的 CE 行为，测试双方网络运营者可同意保持指定速率，并限制流量强度与持续时间，避免影响测试外的业务。这是明确的实验授权，不能当作监测平台日常不停加速的借口。

看清字段，也看清观察边界

去程发出的值与 EC2 不同，或反射端确认写入的回程值与实际收到的 IP 头不同，都能提示沿途某处改变了标记。两个端点的记录还不能单独指出是哪台中间设备。一次没有 CE 的回包，只说明那一个测试包所见。要判断某个部署是否真的实现了草案，需要带时间戳的双向抓包、EC1/EC2/RPE 值、发包频率，以及遇到 CE 后实际采取的速率动作。

这份文件仍是工作组活跃草案，尚未成为 RFC。它提出的运行问题已足够具体：测量系统能够要求路径交出证据，就必须证明自己也会听证据的劝。否则，探针测出的拥塞，有一部分就是它自己的脚印。

草案第 02 版 · RFC 8972 · RFC 8762 · RFC 3168