摘要

  • RFC 9743 规定：面向通用互联网、却缺少互联网规模实证的拥塞控制方案，必须走 Experimental；实验性规范不应默认启用，只应在主动测量且能够停用的环境里运行。
  • RFC 状态、产品默认值和生产回退分别属于标准共同体、产品决策者和运行责任人的记录。任何一层都不能替另外两层承担效果。
  • 真正的停用能力包含授权人、控制通道、传播时间、存量连接、替代算法、状态清理和事后验证；一个从未演练的开关还不是退出机制。

发布前的检查表里有一项写着：“支持关闭。”依据是配置文件里存在 enabled=false。测试报告没有记录谁能下令，没有记录命令需要多久抵达全部节点，也没有记录已经建立的连接会怎样处理。替代算法从未接管过实验算法留下的状态。

这一项不能算通过。

RFC 9743 于 2025 年 3 月作为 BCP 133 发布，讨论的是 IETF 应当如何评价新的拥塞控制算法规范。它不定义某个算法，也不直接管理运营商或产品的发布。但它给生产治理留下了一个极其清晰的边界：实验性规范不应成为默认，只应部署在能够主动测量、并能在病态行为出现时将其停用的地方。

这里至少有四个独立动作：标准文件标注状态，产品决定默认值，观测系统定义测量范围，运行团队执行退出。把“Experimental”贴在发行说明里，不会自动完成后面三件事。

标准不是生产开关

RFC 9743 用 CUBIC 和 BBR 说明了现实顺序：新算法的广泛部署并不以 RFC 发布为硬门槛。CUBIC 在进入 Standards Track 之前已经占据相当规模；BBR 的实现与部署也在完整标准化之外持续演化。

这不是说公开规范没有价值。规范让不同实现者能够理解同一机制，让隐含假设暴露，让独立团队有机会验证歧义，也让共同修改成为可能。问题在于，规范证明的是一套被描述和审议的设计，不是任何具体二进制、参数或网络的实际状态。

因此，没有 Standards Track 不能证明生产里不存在；进入 Standards Track 也不能证明每个实现都安全。代码版本、编译构建、配置、目标人群、路径和队列仍然需要自己的证据。

Experimental 是待补证据，不是危险判决

RFC 9743 让 Experimental 和 Standards Track 面对相似问题，但要求的确定程度不同。面向通用互联网、却没有互联网规模实证的方案，必须请求 Experimental。已经拥有经测量的大规模部署记录、并有可靠数据表明安全与设计稳定的方案，可以直接寻求 Standards Track；这些数据并不免除其他评估。

实验性规范应解释为什么选择这个状态，以及晋级还需要什么信息。这可以形成一份缺口清单：是否只有一个实现，是否缺少无线场景，是否没有与实时流量共存，是否未覆盖 multipath，是否无法证明回退。

Experimental 不等于不安全，Standards Track 也不等于保证安全。RFC 9743 还要求算法规范的摘要说明 IETF 是否形成“适合互联网安全使用”的共识，并指出不建议部署的环境。安全与推荐是两项判断：某个机制可能不会破坏网络，却在某类路径上表现很差。

状态改变了决策者的举证责任，却不会修改任何产品设置。

主动测量必须回答“测到了谁”

拥塞控制作用于共享资源。新算法自己的吞吐和时延变好，不代表共享瓶颈上的其他流没有付出代价。RFC 9743 要求评估与标准 IETF 拥塞控制——包括 Reno、QUIC 拥塞控制和 CUBIC——的竞争，也要考虑已广泛部署的非标准机制。

损害不只是带宽份额。它还包括额外时延、丢包与饥饿；在全部反馈消失时必须退让。短流与长流要分开，因为大量短流可能一直处在 slow start，稳态图表根本看不到它们。实时流往往追求有限吞吐和更紧的时延，不会用“是否占满链路”表达自己的成败。

所以“主动测量”必须绑定算法版本、实现构建、参数、启用组、基线组、流量类型、观察点、时间窗、队列、路径类别和竞争算法。分母必须包括可能被挤出的流量，而不只是参加实验的连接。

如果仪表盘只显示参与者，绿色也可能是一种选择性失明。

证据来源并不是单向阶梯

仿真可以快速覆盖大量极端组合，却可能没有真实实现的缺陷。实验室可以稳定复现一种病态，却不能说明它在互联网出现的频率。多个独立实现可以暴露规范歧义，也可能共同继承同一错误假设。受控实验能连接机制和运行；互联网规模观测能看到真实混合，却可能淹没稀有路径。

RFC 9743 没有把某一种方法封为唯一答案。它鼓励在 Experimental 或 Standards Track 发布前取得实际实现经验，多团队实现与独立评估可以增强信心。只有一个实现也并非绝对不能发表；尤其在 Experimental 场景下，如果它被广泛使用、开源且显示积极影响，仍可能有合理依据。

关键不是证据数量，而是每份证据的授权范围。一次仿真可以支持稳定性假设，不能证明部署普遍性。大规模平均值可以支持常见条件下的表现，不能消除边缘条件。两个实现可以证明可复现性，不能证明产品默认值应当改变。

评估矩阵不能压成一个分数

RFC 9743 要求考虑防止拥塞崩溃、避免过度排队、控制高丢包、同算法流之间的公平以及短流影响。混合算法场景还要评价饥饿风险、反馈完全丢失后的退让、与通用算法及实时流量的共存。

面向通用互联网时，tail-drop 队列必须评估。依赖路径信号的机制必须考虑隧道。固定有线链路提供基线，无线链路带来无线丢包、容量变化、介质接入时延和链路层重传抖动。

特殊场景还包括 AQM、网络 circuit breaker、最小时延变化、受限设备、高时延、恶意节点、严重乱序、短暂事件、突然换路、multipath 与数据中心。RFC 9743 明确指出，互联网规模测量未必能暴露不常见场景。

文件通常不规定统一数字门槛。共同体必须考虑这些标准；当一个 SHOULD 项没有满足时，必须记录为什么缺口可以接受。决定来自透明判断，而不是打勾数量。

“受控环境”需要可执行边界

只在受控环境运行的算法，可以用该环境的真实数据，而不必证明全互联网适用。但它必须说明如何限制范围、是否与互联网流量共享资源，以及协议被桥接到互联网路径后会怎样。

“仅限数据中心”是一句目标，不是隔离措施。备份隧道、混合云边缘、共享广域链路或策略失效都可能把流量带出假定范围。如果书面限制无法强制，可能需要协议或网络机制实现约束。

默认值也存在同样的假边界。一个名为 opt-in 的选项，如果所有新设备都自动加入、旧路径被移除，实际上已经成为默认。需要测量真实暴露，而不是读取配置字段名字。

关闭开关是一条分布式链

生产停用至少要回答：谁有权限，命令如何认证，目标如何确定，传播需要多久，未连通节点怎么办，现有连接是否切换，新连接采用什么替代算法，旧状态如何清理，以及执行后由谁确认流量真的改变。

只停止新连接，可能让旧连接继续使用实验算法。改变默认值，可能不影响被固定的策略。回滚软件，可能保留缓存的拥塞窗口或路径状态。控制面分区，可能让一部分节点永远看不到命令。替代算法也可能错误解释前一个算法留下的状态。

因此，关闭能力必须在扩大实验前演练，并对执行后效果做观测。配置写入成功只是控制面收据，不是网络已回退的证据。

RFC 8084 的网络传输 circuit breaker 是相邻但不同的保护层。它可以在资源使用过度时减少或终止流量。RFC 9743 希望良好算法在触达这条线之前自行反应。circuit breaker 不能替代算法安全，也不能替产品的停用责任。

标准晋级与默认启用必须分开批准

从 Experimental 晋级 Standards Track，是对规范证据成熟度的更新。从选配改成默认，是对生产暴露的扩大。两项决定可以同时发生，但必须有两份责任记录。

晋级材料应把所测算法精确连接到实现版本，保留负面结果，说明未覆盖场景，并逐项关闭早期缺口。默认启用还需要本地队列、路径、应用、竞争算法、支持压力和回退能力的证据。

如果两项决定合并，产品可以借 RFC 状态掩盖自身选择；标准也会被迫承担它没有测量的后果。

RFC 9743 真正要求的是对不确定性进行运行化管理。实验可以大胆，但必须知道覆盖谁、影响谁、何时停止、如何退回。开关只有在走完整条链后，才配得上“退出机制”这个名字。

来源