摘要

  • MQC 让相邻运营商用同一种语言描述可绑定的本地 QoS 能力；它不是覆盖整条路径的证书，也不替任何一方承担远端域的责任。
  • 真正可审计的端到端记录必须把双向实际路由、逐域测量、带宽与准入状态、客户请求、故障归因和补救动作绑定在同一时间窗口内。

共同标签最容易制造一种危险的视觉效果：五个网络域都亮着绿灯，看上去整条路径自然也是绿色。RFC 5160 的结构恰恰不允许这样推断。

共同语言没有创造共同观察者

文档先描述了它不接受的模式。若上游运营商向邻居担保穿越多个下游网络后的性能，服务中断时，索赔只能沿合同链一跳一跳传递，直到找到真正有问题的域，再反向追讨。路径会变化，运营商未必彼此认识，还可能相互竞争；最靠近客户的一方却要为自己既不控制也看不见的远端性能负责。

更严重的是，一个本地合同的重新谈判可能影响许多依赖它的外部承诺。RFC 5160 把这种依赖称为“SP chain trap”，并把所有人都难以修改合同的状态比作“冻结”。

替代方案很克制：运营商只向直接邻居担保穿越自己网络域时的性能。责任只有一跳。这个规则并不否定端到端服务，而是拒绝让一份双边合同冒充整条路径的所有权证明。

MQC 解决可比性，不解决证据保管

每个运营商可以用自己的工程方法实现 QoS。RFC 5160 只把域内能力抽象成本地 QoS 类，即 l-QC，并以单向时延、时延变化和丢包率描述它。跨域动作是把本域的 l-QC 与相邻下游域的 l-QC 绑定。

Meta-QoS-Class（MQC）规定两种本地类若要绑定必须共同满足哪些边界。它可以说明适合哪类应用、性能区间、流量约束以及资源相对于负载的条件。双方仍须另行约定带宽，服务可用性和修复时间也可能需要写进合同。

因此，MQC 的证据含义很窄：相邻双方曾把两种能力判断为兼容。它不证明实际包走了哪条路，不证明已准入流量没有挤满约定容量，也不证明后续每个域仍处在同一个 MQC 平面，更不证明各段时延、抖动与丢包合成后仍符合客户门槛。

RFC 的可扩展性来自“短视”：运营商只依据自己的类和邻居的类决定绑定，不查看一个域以外的状态。这个限制减少了全局协调成本，却也意味着没有一个双边参与者天然持有全链证据。

同一标签下仍有三次分离

第一，分类与容量分离。两个 l-QC 同属一个 MQC，只说明能力类型兼容；带宽不在 MQC 定义里。若准入量超过另行约定的容量，类别仍然正确，结果却可能失真。

第二，控制面与测量分离。文档设想路由传播时各域可以附加自己的时延、抖动与丢包贡献，再让入口域计算路径总量。这种计算只有在域序列、数值有效期和实际所选路由一致时才成立。旧广告并不会使新路径获得旧证据。

第三，去程与回程分离。框架中的运营商协议是单向的。反向协议可以另签，但互联网的两个方向经常穿越不同运营商。一场交互式会话需要两条路径、两组域序列和两次合成，不能把去程的绿灯复制成回程结论。

甚至“选择最优路径”也不是结果证明。RFC 5160 提醒，所有边界路由器都追逐同一条看似最佳的 QoS 路径，可能把流量集中到该路径并恶化性能。决策依据、已安装路由和用户体验属于不同现实层。

应当保存什么

领导层需要的不是一个绿色 MQC 徽章，而是一份带时间边界的组合凭据：客户请求及授权流量画像；去程和回程实际经过的域；每份双边协议的版本与方向；每个边界生效的 l-QC 映射；已准入流量与约定带宽；逐域测量窗口；指标合成规则；端到端实测结果；以及未达标时的定位、责任和补救记录。

这份记录不改变 RFC 5160 的责任设计。远端运营商仍不必承担自己从未签署的合同。它只是让面向客户销售服务的一方能够区分：本域违约、下游违约，还是从一开始就没有证据证明这些局部组件能组成所承诺的整体。

最后一种情况尤其重要。每个域都可能满足自己的上限，整条路径仍可能超过应用阈值。这未必是谁作弊，而可能是采购与上线决策把“兼容”误写成了“充分”。

来源