摘要

  • STAMP 的 Reflected Test Packet Control TLV 允许发送端指定响应包长度、数量和间隔；反射端则必须同时执行数据速率与总负载量限制，并受回程接口 MTU 约束。
  • MTU 分支和速率/总量分支都会返回一个带 C 标志的包。包长可以帮助发送端区分两大类原因，但真正可审计的使用还需要一份“反射限制来源收据”，把信号与本地策略、具体原因和测量适用范围连接起来。

监控系统最喜欢把复杂状态压成一列。收到响应，写“成功”；C 标志为一，写“受限”。可是对一次主动测量来说，“受限”不是一个足够稳定的事实。它可能表示所请求的单包长度超过回程接口 MTU，也可能表示单包可以发送、整串响应却超过本地速率或总量上限。两种情形最后都只回来一个包，后续行动却不应相同。

draft-ietf-ippm-asymmetrical-pkts-14 为 STAMP 增加可选的非对称响应机制。传统的一问一答在相关维度上是对称的；新 TLV 可以请求不同的响应长度，也可以让一份请求触发多份响应，并规定相邻响应之间的纳秒间隔。它可用于模拟上下行不对称流量、支持速率测量，也可减少组播测量中的无用数据。

这种能力同时带来放大面。一份很小的控制包可以要求反射端输出更多字节；若送进组播树，多台反射端还可能一起回应。草案因此要求实现提供管理开关并默认关闭，要求保护身份，建议使用 STAMP 认证模式或 HMAC TLV，并强制反射端限制输出速率和总负载量。

这些约束不是失败后的补丁，而是机制成立的前提。治理问题在于：约束一旦改变测试，谁保存它的版本与理由？

C 把两种物理原因压在一起

反射端先计算响应包应有的长度。它不能小于基础反射包与适用扩展所需空间，也不能小于发送端请求、经四字节对齐后的长度。收到的 Extra Padding 不会原样算入基础长度；需要增大时，再用 Extra Padding 补足。

若算出的长度超过返回发送端所用接口的 MTU，反射端设置 C，并只发送一个长度等于该 MTU 的包。这里改变测试的是回程接口可承载的包形状。

即使包能装下，请求也未必能完整执行。支持该 TLV 的反射端必须为生成的 STAMP 负载同时设置“每秒字节数”与“总字节量”限制。任何一项被突破，同样设置 C，同样只发一个包；只是这个包保持按规则算出的长度。这里改变测试的是资源保护策略。

草案给了发送端一个实用判断法：返回包比请求长度短，指向 MTU 分支；返回包等于请求长度，指向速率和/或总量分支。这让 C 不至于成为完全不透明的告警。

但“速率和/或总量”依然没有拆开。发送端也看不到阈值数值、计量窗口、突发处理、并发会话占用和配置代次。MTU 分支没有随 C 保存接口身份和观察时间。包长支持的是远端推断，不等于反射端对内部决策作了确切证明。

一个合规响应，可能已不再是原计划的实验

若任务只是确认反射端可达、能处理请求，单个响应可能足够。若任务需要观察按特定间隔发出的多包序列，单包便不能替代它。协议流程完成与测量方法完成是两个判断。

草案把工具边界写得很清楚。TLV 负责长度、数量与间隔，接入速率的指标和测量方法不在其范围内。停服测试可以有意用高负载寻找瓶颈；在服测试则应从低速率、低总量开始，逐步增加。C 对两种任务的含义不同：前者可能说明尚未施加预期负载，后者可能说明保护措施及时介入。

因此，C 不能直接写成“测得容量”。反射端上限是设备与网络保护参数，不等于客户签约速率。回程 MTU 也不等于完整路径诊断。修订 14 还明确提醒，大规模主动测量可能违反服务提供商对服务设置的限制。认证通过只证明身份和完整性，不授予任意放大量。

ECN 也不能替代这段解释。CE 表示早期拥塞，而不是丢包；什么程度算“显著”、采取什么动作，取决于部署与运营目标。主动探测本身还可能促成 CE。若系统不保留请求负载、实际输出和策略，最后的拥塞信号就容易被误读成纯粹的外部网络状态。

组播让分母也变成策略

在组播环境里，发送端位于根，许多 Session-Reflector 位于树叶。一份请求可能产生大量汇聚到同一目标的回复。二层和三层 Address Group sub-TLV 可以按地址掩码或 IP 前缀筛选反射端。草案建议第一次保守地请求一个响应，让发送端先观察放大规模。

收到七个包，并不能自动说明覆盖率。需要先知道多少反射端符合选择条件，多少实际加入了树，哪个选择器最终生效，各端是否触发本地限制，以及中间是否丢包。回复减少可能是刻意抽样、保护性抑制、成员变化或传输故障。

草案还允许某些组播环境通过修改控制 TLV 的选择字段来减少回复。若启用完整性保护，路径中的修改会导致验证失败，除非修改者处于信任边界内并能重新计算保护值。最终包通过校验，只能说明最后一段受保护状态连续；它不自动公开谁授权修改、修改前的请求是什么。

这正是“信任”与“可追责”之间的空隙。可信路径元素可以有权保护网络，但其决定不应从测量证据中消失。

给限制留下一份可重放的收据

反射限制来源收据首先绑定会话：发送端、反射端、传输、STAMP 模式、认证或 HMAC 配置、序列证据，以及两端软件与配置版本。随后保存原始请求中的长度、数量、间隔、组选择条件和回程控制。

第二部分记录目的。在服还是停服？预期使用哪种测量方法？谁批准了负载包络和窗口？需要保护哪些用户流量？一份语法正确且认证有效的请求，仍可能超出它被授权执行的场景。

第三部分属于反射端：实际出接口、当时观察到的 MTU、速率上限、总量上限、单位、计量窗口、突发规则、并发会话算法和策略版本。商业敏感值可以只在内部保存，跨团队记录也可使用可验证摘要；关键是日后能还原当时是哪一代规则在决定。

原因字段不应只写 C。应区分 MTU、速率、总量以及两者同时命中。若只有发送端依据包长推断，就标明“推断”；若反射端日志能证明精确分支，再附上本地证明。不要把观察者推断升级成执行者声明。

最后写清测量后果。这个包也许仍能证明到达、时序或完整性，却不适合原定的多包速率计算；也许要降低请求、换到维护窗口或转为停服测试；也许因为组播分母未知而必须剔除。审阅人、到期时间、例外、纠正历史和回滚权把收据闭合。

这份收据放在协议外即可。它不是新 TLV，也不要求 IANA 分配新字段，更不是说一位标志设计错误。包负责快速互操作，收据负责让组织不把现时配置错当成历史事实。

沉默、U 与 C 不能合成一个“异常”

请求响应数量为零时，反射端不得发送响应，通常还应丢弃收到的测试包，不过本地策略可以覆盖后一个默认动作。若真正意图是“No Reply Requested”，草案更推荐已有 Return Path 控制机制。这个沉默不是丢失的 C 响应。

U 标志处理的又是其他问题。互相矛盾的 TLV 组合可触发 U 与运营通知；序列号不单调递增时，为缓解重放风险，反射端也可只回一个 U 包。草案同时强调，这种序列现象可能来自重排或重复，并不证明攻击。

若平台把 C、U、CE 和无响应全部压成“测试降级”，它恰好抹掉了调查所需的责任边界。精确治理并不要求更多颜色，而要求每种状态保持自己的证据含义。

来源

  1. 当前文档记录
  2. 文档历史
  3. 修订 14 HTML
  4. 修订 14 文本
  5. 修订 14 XML 源文件
  6. 修订 13 文本
  7. 官方 13–14 差异
  8. IPPM 工作组
  9. IPPM 文档
  10. RFC 8762：STAMP
  11. RFC 8972：STAMP 可选扩展
  12. RFC 9097：UDP 速率测试
  13. RFC 7497：速率测量问题
  14. RFC 9503：STAMP 回程控制
  15. RFC 8085：UDP 使用指南
  16. RFC 1982：序列号算术
  17. RFC 7799：主动与被动测量方法
  18. RFC 7942：实现状态
  19. Lu Heng：Minimum Initial Specification, Localized Future Decision
  20. Lu Heng：The Policy Mirror