摘要

  • RFC 8570 希望用于流量工程的时延测量不要随业务负载显著波动，并建议不计入排队时延。这是一项有意的测量边界，不等于网络没有拥塞。
  • 路由通告还可能经过平均、过滤、阈值判断与节流。接收端看到的平稳数值，不能直接充当普通业务流量此刻体验良好的证明。
  • 企业需要分别回答两个问题：用什么信号选择路径，用什么证据判断服务。决定前一条曲线如何变得平稳的人，也应说明哪些问题必须由后一套观察来发现。

先别急着判哪条曲线错了

设想一次服务质量复盘。业务部门说响应变慢，网络团队拿出的路由时延曲线却很平稳。讨论很容易变成二选一：要么业务感受不可靠，要么网络监控失灵。

还有第三种可能：两边从一开始就在观察不同的东西。

这不是某次真实故障的还原，而是一个用来检验职责边界的场景。若选路依据刻意避开业务排队造成的等待，那么它保持平稳与用户遇到等待，并不必然矛盾。此时要查明的不是谁的数字更有权威，而是各自的测量究竟包含了什么。

这一区别常被“低时延网络”几个字压平。路径的某些基础条件有利于降低时延，并不意味着所有业务包在任何负载下都能获得相同体验。用于选择路径的稳定参考，与用于判断服务的敏感观察，可以同时有价值；前提是没有人把前者的适用范围悄悄扩展成后者的保证。

标准主动留下的空白

2019 年 3 月发布的 RFC 8570 定义了通过 IS-IS 分发链路性能信息的扩展。它在引言中明确提出，时延测量不应随提供给网络的业务负载显著变化，因此不应计入排队时延。这里的“不应”对应标准的建议级要求，而不是可以脱离所有条件宣称的绝对禁止。

对于由一段路径构成的转发邻接，标准举出的办法包括：采用排队很少的流量类别进行测量，或者汇总组成链路的测量值。这些是可选示例，不是所有设备都必须采用的唯一实现。具体如何采集、接收信息后如何采取行动，仍不在该文件规定的范围内。

这意味着某些等待没有进入数值，可以恰恰是测量达到了设计目的。它想提供的是较少受当前流量摆动影响的参考，而不是把某个业务包经历的一切都装进一个字段。

OSPF 对应的 RFC 7471 也表达了这一思路。它同样建议链路传播时延测量不要明显跟随负载，并列出低排队测量流量等办法。两个标准的共同点不是要求运营者忽视用户，而是把性能信息的分发与它的采集、使用分开讨论。

因此，不能因为存在一条测量曲线，就省略“它测的是哪类流量”这个问题。为了得到平稳参考而受到特殊处理的探测包，不会因为也使用 IP，就自动代表普通客户的业务包。

为什么更灵敏未必只有好处

可以用一个条件性的控制场景理解这种克制。一个选路系统看到某条路径此刻较空闲，于是把流量移过去；流量迁移又改变了它下一次看到的负载。如果新的等待马上成为再次迁移的依据，系统观察到的环境就部分来自自己刚刚做出的决定。

这并不证明某种已部署系统必然振荡。是否出现不良反馈，还取决于决策方法、备选路径、流量规模及时间安排。RFC 8570 没有替运营者规定这样的控制器，也没有保证排除排队后所有稳定性问题都会消失。这个场景只是说明：测得更快、反应更快，不能单独构成一份完整设计。

即使尚未发生流量迁移，更新本身也有成本。性能信息要传播，其他路由器要处理。把单个测量端的刷新频率提高，并不能推导出整张网络都将受益。局部更及时，与整体能否承受更密集的变化，是两项不同的判断。

商业语言容易把响应速度排成一条只有上升方向的刻度。更短的时间看上去总像升级，但控制系统还必须回答：更快捕捉的是哪一种变化，接收方为此多做了多少工作，新增风险由谁接受？

通告之前，数值已经经过选择

RFC 8570 为这种分发成本设置了多种可配置控制：测量和通告间隔、代表性的平均或过滤、变化阈值、抑制与节流。它建议默认测量间隔为 30 秒、默认通告节流值为 120 秒，并允许在迁移或动态测量不可用时使用静态配置。默认值不是实际部署证明，也不是某项业务必定在多少秒内恢复的承诺。

一个接收端看到的数字，因而可能有几个不同的时间背景：原始现象什么时候被观察到，区间或过滤器什么时候形成了数值，以及该数值什么时候被通告出去。只显示最后收到通告的时刻，不能完整表达这些差别。

假如一个团队保存逐次观察，另一个团队只保存满足阈值后发出的通告，后者的记录更安静并不奇怪。安静可能表示没有变化达到再次通告的条件，而不是前者看到的变化从未发生。

把两份记录直接放在一起争论，会丢失最重要的一层：它们各自承担什么任务。如果通告原本服务于选路，不能因为存储方便，就未经讨论把它变成唯一的服务体验档案。那不是简单的数据复用，而是在改变系统的职责。

业务观察也需要自己的定义

另一份标准提供了有用的对照。RFC 7679 定义了特定 IP 包的单向时延：从发送端送出首个比特，到接收端收到最后一个比特。它要求准确报告测试包的类型与处理条件，并说明包长、协议、端口以及特殊待遇等因素可能影响结果。校准误差、长时延与丢包的区分、可获得的路径信息，也会影响解释。

这不是说 RFC 8570 必须改用同一套方法。重要的是，独立的业务观察也不能只剩一个没有说明的探针。组织归属独立，不代表流量待遇独立；如果两个探针都走同样的低排队类别，它们可能共同绕开了企业真正想了解的体验。

比较结果时，应先问它是否覆盖相关业务方向，是否对应所讨论的处理类别，以及测量方法有没有发生变化。只有这些条件足够清楚，差异才可能被进一步解释为拥塞、选路不合适或其他服务问题。

RFC 7679 将最小时延与轻负载下的传播和传输条件联系起来，将较高值视为可能存在拥塞的迹象。这是对已知测量条件的解释，不是让人把两个不相干的仪表盘数字相减，就把余数叫作排队时延。

手工值不必然是不诚实的值

静态配置尤其容易暴露组织边界。动态测量尚未具备时，使用一个经批准的参考可以是合理过渡。问题不是“手工”两个字本身，而是后续使用者是否仍被告知它来自持续观察。

如果容量规划以手工参考为依据，审批者就应知道接受的是这种安排。以后换成动态测量，单位仍然是微秒，也不意味着新旧序列具有完全相同的含义。曲线突然改善，可能是测量方式变了；曲线变差，也可能如此。

这里并不需要为每个字段设立委员会。需要的是在数字跨越团队时保住它的用途与来历。选路团队、服务团队和商业团队可以复用同一个字段，但不能在不说明的情况下各自给它附加一份不同承诺。

平稳之外，还有未完成的工作

回到开头的复盘场景。如果排查发现客户遇到的等待本来就不属于路由指标要反映的内容，不能据此宣布事件已经结束。发现边界，只是让接下来的责任更清楚：需要另一个观察对象、另一种诊断，或者重新审视服务承诺与网络设计是否匹配。

同样，也不应立即把通告间隔调短作为补救。更快发送一个本来不包含相关现象的指标，未必能补上那个缺口，却可能增加信息传播的负担。

本文依据公开标准分析这项取舍，没有测试设备、配置、客户流量或实际选路结果。由此得出的经营判断是：企业必须有人负责解释“选择路径所依据的性能”与“承诺交付给客户的性能”之间的距离。平稳的路由参考可以工作得很好，但不能靠它的平稳替其他职责结案。