SR Policy 的质量分数由谁决定流量去向？

摘要

2026 年 10 月 28 日的个人 Internet-Draft建议持续监测活动 Candidate Path 内多条 Segment List 的状况，用可配置的质量评分函数调整相对转发权重。它描述测量、上报、汇总、计算与执行，但没有规定统一的评分公式。
RFC 9256按 w / 权重总和分配的是流的目标份额，并指出平台实现会影响精度。权重变化可以说明头端改了转发规则；字节量、应用时延和体验要另取实测记录。

三条路，一条发病，自动驾驶先问诊断权

草案的示意图给一条活动 Candidate Path 配三条 Segment List，初始权重相等。一条路径发生退化，静态配置仍按原比例把流量送过去。作者把这种惯性当成问题：既然有监测数据，头端为什么还装作没看见？方案是把测量接进控制闭环，让较好的路径得到较大的权重。这个直觉并不难懂；真正难的是“较好”要替谁服务。

路径 A 时延低，但可用带宽吃紧；路径 B 余量较大，尾部时延却更差。长时间的训练传输和短促的推理请求，可能给两条路打出相反的名次。草案 01 版专门加入这种 AI 计算负载混合的动机：大流追求持续吞吐，小型请求与控制消息看重初始和长尾时延。这是作者提出的场景，不是某个已命名网络的测试结果。它恰好说明，单个“质量”数字背后总有一个目标函数：为哪种流争路，牺牲哪种流的优先级。

草案把动作拆成一条清楚的责任链。中间节点和终点节点可监测时延、丢包、利用率等指标；报告送给逻辑上的 Candidate Path Quality Agent（CPQA）；CPQA 汇总每条 Segment List 的数据，算出质量分数，再通过函数 F 得到新权重；头端将权重装入转发表。它要求权重与质量分数成正比，也把“质量”的定义、指标组合方式留为可配置项。让两套系统遵循相同的框架，并不保证它们看到同一批样本时会改出同一组权重。

RFC 9256 写的是流的份额

不能让“权重”这个词替结果做证。RFC 9256 的 SR Policy 架构说明：策略可有多条 Candidate Path，活动路径中的 Segment List 承担实际转发；存在多条列表时，头端按加权 ECMP 在流之间分配。某条列表权重为 w，目标份额是 w / 所有列表权重之和。RFC 还指出，分配精度受平台实现影响。这个等式没有把流的大小写进去，也没有承诺等比例字节、等比例容量或更好的应用体验。

于是，草案里“三条等权重列表仍有三分之一流量走坏路”的例子，应按构造的转发场景读。一个大流足以占掉比许多小流更多的链路资源。动态调权后，拿到更多流的路径可能只增加少量字节；被降权的路径也可能仍背着一条沉重的大流。头端采用的哈希方式、流量构成和实际转发状态都会改变结果。控制器日志只能说它下发了什么，不能代替头端已安装的权重，更不能代替应用测到的时延。

草案有意把手伸得有限：它调整的是当前活动 Candidate Path 内各 Segment List 的权重，不改变 Candidate Path 的优先级，也不改列表的组成。它另提一套“动态流量调整”模式：识别发生拥塞的特定流，把这些流重定向到较空的列表。前者修改比例规则，后者挑出具体流，两种操作需要不同的触发条件和撤回记录。文章若只写“自动换路”，就把这个重要边界抹平了。

同一把尺子，可以装在控制器，也可以装在头端

CPQA 的位置不是固定的。集中模式让控制器收集报告、计算权重，并经南向接口把权重组合发给头端；草案把 PCEP 列为接口例子。分布模式让头端直接收报告、在本地计算并安装权重。草案没有定义新的 PCEP 报文；IANA 章节此时也没有提出编号申请，只说后续协议扩展可能需要。它给出的是决策框架，不是一只所有设备已经装好的标准旋钮。

把评分放在中心，便于对多个路径使用同一规则，也可能让错误规则同时影响多个头端。把评分放在本地，可凭近处状态及时动作，却可能让相邻头端对同一“质量”各有解释。草案允许质量定义可配置，就意味着配置本身需要主责人和版本记录：哪些监测点，采样窗口多长，缺失或迟到数据怎样处理，指标如何汇总，F 怎么把分数变成权重，哪一组权重最后进了转发表。

消息可信也不等于评分可靠。草案要求监测点、CPQA 与执行者之间的消息必须认证，并建议使用 TLS 或 TCP-AO。报告可能暴露网络内部状态，文本建议在涉及隐私时考虑加密；它还要求系统能抵御虚假报告洪泛，建议限速和核实报告来源。认证可以证明报告从谁来，却不能证明采样点足以代表整个路径。质量分数即使由诚实设备算出，也可能服务了错误的业务目标。安全通道和正确决策必须各自留证。

闭环还有时间问题。草案说要做抑制，避免权重随短暂波动来回摆，却没有在这个框架中给出适用于所有网络的门槛或算法。反应过快，刚转走的流会改变利用率，触发下一轮计算，系统追着自己制造的波动跑；反应过慢，坏路继续载流。阈值由谁设、何时改、能否恢复旧值，都是运营选择，不是“自动”二字附带的免答题。

版本记录也有边界。2026 年 7 月的 00 版已有监测—报告—计算—执行的主链。10 月的 01 版加入 AI 负载动机和第三位作者，并未第一次发明这套闭环。Datatracker将其列为个人 Internet-Draft。官方材料没有给出一条把样本、F 配置、权重安装与应用结果连起来的已命名运行轨迹。有了这样一条轨迹，才能评价一个具体实现究竟把多少“更好”送到了用户那里。