摘要

  • CATS度量定义第11版来自9月4日合并的PR 42，新增可选的观测时间、有效区间和一整组运行考虑；它仍是工作组Internet-Draft，并非RFC。
  • 8月的公开讨论已经明确否决“每条度量都携带函数标识”的方案，理由是跨厂商函数应在初始化时离线约定，避免选择器在运行中动态调整算法。
  • 新版要求把分数范围、归一化方法与参数、聚合公式与权重、比较方向写入受版本控制的正式配置清单，并离线同步到决策组件。
  • 运行时组件必须假定这些分数完全可比，但度量字段没有清单版本、摘要或激活批次。签名正确、时间新鲜的分数，仍可能来自不同规则。
  • 最小补丁不是在线重谈算法，而是在采纳分数前核对同一清单身份，预先声明不一致时的降级动作，并保留连接分数、清单和决定的回执。

这次更新补的是运行规则

9月4日，CATS度量定义仓库的维护者合并了PR 42。对应的合并提交进入第11版固定文本。Datatracker历史记录了这次更新；当前页面显示它是活跃的CATS工作组文档，IESG状态仍为“I-D Exists”。这不是已经完成的标准，更不是部署证明。

但这次改动确实比文字修订更有分量。CATS试图让流量选择同时理解网络状态和计算资源状态。时延、利用率、可用内存等原始数据单位不同，不能直接排序。归一化函数把它们压到共同尺度，聚合函数再生成一级分类分数或二级全局分数。一个看似简单的“7”，实际上取决于输入上下界、曲线参数、各类权重以及“高分更好”还是“低分更好”。

第11版要求多厂商环境在部署前把这些事项谈妥：分数范围、归一化方法及其参数、聚合公式及其权重、比较方向。谈判结果应汇总为正式配置清单，在初始化期间以离线方式同步给需要依据度量做决定的组件，并进行版本管理。

紧接着，草案规定了运行时立场：组件必须假定收到的分数使用了约定函数，彼此完全可比；无需运行时动态协商。这个设计换来了更小的消息和更简单的选择器，也把系统安全地运转所需的关键事实，从消息转移到了配置状态。

工作组不是忘了函数身份

公开记录能防止错误归因。8月初，一位贡献者提出为每个度量实例增加三个字段：所用函数、观测时间和有效区间。PR 41给出了参数绑定的函数标识与注册表文本。它试图让接收方分清三种情况：服务状态真的不同、计算方法不同，或者某个值已经过期。

8月25日，一位草案共同作者在CATS邮件列表回复，明确表示不应在每次报告中携带函数字段。跨厂商的一致性应在初始化阶段离线完成；若让C-PS逐条解析函数ID并动态改变算法，系统会过于复杂。作者们同意加入观测时间和有效区间，但把二者保留为可选字段。

提案人随后也接受了这条边界：CATS框架并未暗示逐消息重谈，离线一次性约定可以比反复声明更强。于是第11版加入Observation_Time与Validity_Interval，没有加入Function。PR 41下的作者评论说PR 42吸收了两个时间字段；截至本次取证截止，PR 41仍然开放。

因此，不能把缺少函数字段写成工作组的疏忽。它是一次公开说明过的复杂度选择。真正需要审查的是：当系统拒绝逐条携带函数身份后，是否有别的机制证明离线约定仍在所有运行组件上保持一致。

Git里的版本不等于机器里的版本

配置仓库可以完整保存M1、M2与回滚记录，运行中的组件却仍可能各持一版。第11版说清单要受版本控制并在初始化时离线同步，但没有定义标准清单摘要、激活纪元、全体完成条件，或者某个节点漏掉更新后的处理规则。

合并前已经有人看到这条缝。PR 42的一条审阅意见指出，在分布式系统中不能假定同步永远成功，并建议要求检测、报告失败或不完整的同步。最终文本保留了“正式清单、离线同步、版本控制”，没有纳入这句建议。单条GitHub评论并不代表工作组共识；它能证明的是，失败模式在第11版发布前已经可见。

设想一次普通升级：选择器和厂商A的生产组件仍运行M1，厂商B的生产组件已切到M2。M2修改了某项归一化上界，或调整了聚合权重。两边都报告二级分数7，消息都有有效签名，发送者也获授权，时间戳和有效期没有问题。选择器看到的是两个相同数字，却看不到其中一个数字已经换了含义。

这是机制示例，不是现实事故指控。草案里的Source可说明数值来自直接测量、估算、聚合还是归一化；Observation_Time说明何时观测；Validity_Interval限制可用时长。完整性与来源验证回答“谁绑定了这些字节”，新鲜度回答“这是否太旧”。它们都不回答“生产者与选择器是否依据同一份M1”。

新增告警仍差一个维度

OPSDIR对第10版的早期审阅给出“Has issues”，要求草案补上多厂商可比性、策略标识、校准、故障处置、管理接口预期和迁移叙事。第11版认真回应了许多内容。

新版比较一级与二级指标在可见性和开销上的代价，建议限制常规更新频率，也允许状态事件触发额外更新。度量缺失或不够新鲜时，运营者可在两三个测量窗口内使用“最后已知良好”值、降低实例优先级或排除实例，或者退回只看网络信息。它还建议为新鲜度失败、组件故障和分数异常设置告警，记录降级事件。

这些动作都有价值，却未必能发现版本偏差。使用旧清单的组件可以完全健康，M2产生的分数在M1看来也可能非常合理。把一个值标为“最后已知良好”时若没有记录它依据的清单，缓存反而会延长语义混用。

当前CATS框架把系统限定在单一管理域，并要求参与组件使用相同的归一化和聚合函数。这减少了跨组织的权限冲突，但不会让部分发布从工程上消失。恰恰因为同一运营者能控制两端，证明配置一致的成本应该更低。

需要的是清单绑定，不是在线谈判

修复不必推翻8月的决定。选择器无需逐条接收sigmoid参数，也无需现场重新计算所有分数。系统只要在采纳分数前建立一份很小的共享状态：清单的规范标识与摘要、管理域和组件范围、版本或激活批次、生效时间、同步完成状态和例外节点。

生产者与选择器分别证明自己当前激活的摘要。这个摘要可以随度量发送，可以绑定到经过认证的会话，也可以由管理平面在准入分数前核对。落在哪个协议位置不是本文要替工作组作的决定。最低要求是：任何一次选路之后，都能把生产端的计算与选择端的解释连接到同一份清单。

不一致时的动作可继续由本地决定：拒绝该值、退回解释更透明的一级指标、只使用网络维度，或等待升级完成。回执应保留生产者、选择器、分数、观测与有效时钟、双方摘要、所选降级、告警确认、最终决定和恢复条件。权重、阈值等敏感配置不必公开；摘要能证明身份，而无需泄露内容。

RFC 8911提供的是一种有限先例，不是CATS现成规则：它用固定参数约束性能度量的身份，使不同实现知道自己测的是不是同一件事。CATS可以选择别的承载方式，但不能只靠“应该已经同步”的句子保存这层含义。

来源

  1. IETF Datatracker：CATS度量定义
  2. CATS度量定义第11版
  3. CATS度量定义第10版
  4. Datatracker版本历史
  5. OPSDIR早期审阅
  6. CATS邮件列表：共同作者说明离线约定
  7. CATS邮件列表：提案人接受边界
  8. PR 41：逐实例来源提案
  9. PR 42：运行考虑
  10. PR 42合并提交
  11. 当前CATS框架
  12. RFC 8911
  13. Heng Lu：最小共同规范与本地决策