摘要

  • RFC 9971 用已声明的负载、时长、丢包目标和边界来描述数据平面试验；它没有给出放之四海皆准的性能裁决。
  • 若没有流量画像、搜索目标、方法偏差和完整报告，一个数字不能证明 SLA、应用体验或已部署的可用能力。

数字不能脱离试验边界

Maciek Konstantynowicz 与 Vratko Polak 共同署名的 RFC 9971《Multiple Loss Ratio Search》，针对软件网络测试中的实际难题：二分搜索耗时，试验结果会受噪声影响，而连续试验互相矛盾时，“零丢包吞吐量”也不再只有一个明确含义。该方法允许同时搜索多个丢包率目标，并要求测试报告保留让结果可解释的要素。

这强化了测量纪律，却没有发现某台设备或某项服务天生不变的“真实吞吐量”。结果属于特定的被测系统、配置、流量画像、试验输入和所选目标。要说生产服务得到保证，还需要生产路径、真实需求、维护和恢复等另一套证据。

测量、选择和报告是不同职责

RFC 9971 将工作分为 Measurer、Controller 和 Manager。Measurer 执行试验，Controller 选择负载和时长，Manager 预配置相关实体并生成 Test Report。试验输出至少包含试验丢包率、有效时长和转发速率；试验结果把输出和输入结合起来。

这些量不能被借用来证明别的事。一次试验中的转发速率不是应用 goodput；较低丢包率并不自动意味着低时延、正确路由、故障恢复、租户可用性或合同履约。每个命题都有不同的控制面和观察凭据，不能由同一张成绩单代替。

多个目标让选择浮出水面

MLRsearch 可以使用多个 Search Goal，通常各有不同的 Goal Loss Ratio。Goal Final Trial Duration、Goal Duration Sum、Goal Exceed Ratio 与 Goal Width 会影响测量时长、可容忍的高丢包试验时间比例，以及相关上下界需要达到的精度。

RFC 9971 并未指定通用配置。测试程序的运营者选择目标参数，Controller 的内部负载选择启发式也属于实现细节。因此，两家实验室即使都说采用 MLRsearch，也不会天然可比；它们仍应披露流量画像、目标、时长、边界和分类方法。灵活性可以更细致地刻画系统，不能被用来把不同含义的数字伪装成同一种结论。

波动是信息，不是可以抹去的麻烦

该 RFC 明确承认不一致的试验：同一负载可能得到不同丢包率，较高负载甚至可能产生较低丢包率。相关上下界为处理这种反转提供保守方法，却没有把已经观察到的波动变成确定性。

报告也应保留预热、重复和与 RFC 2544 试验过程的偏差。RFC 9971 允许偏差，但要求明确记录，并提醒偏差会削弱可比性。较短且可重复的搜索可能非常有用，却不等于它已经构成符合 RFC 2544 的吞吐量结果。

一张可审计的测量回执

有用的回执应写清被测系统及配置、流量画像、提供负载定义、完整目标、相关边界和已声明偏差。生产服务评估随后还要加入独立采集的路径、延迟、负载、维护、故障恢复与合同指标。实验室和生产遥测各有价值，谁也不能替代谁。

Konstantynowicz 的贡献在于让实验室结果更可检查。方法并没有授权这个结果替没有被测试过的生产系统作证。

来源