RFC 3124：一次发送许可还不是一个数据包队列

摘要

应用通过 cm_request 告知拥塞管理器自己有发送需求，却不会把数据缓冲区交给它；cmapp_send 回调只授予一个有时限、有字节上限的发送机会，通常不超过路径 MTU。
许可并不证明某个包已经排队，更不证明对端收到。应用仍须选择或重组内容，用 cm_notify 报告主机实际送出的字节，再以 cm_update 单独提交接收端反馈。

同一条瓶颈，主机里却有许多套记忆

2001 年前后的终端主机，可能同时运行浏览器、音视频程序和其他网络应用。它们各自建立流、估算往返时间、经历丢包，再各自调整速率。即使两个连接面向同一目的地，新连接也可能完全不知道旧连接刚刚学到了什么。网络瓶颈是共享的，拥塞控制的记忆却被锁在不同协议实例里。

RFC 2140 已经讨论过如何在同一对主机的 TCP 连接之间共享部分控制块状态。2001 年 6 月进入标准轨道的 RFC 3124 进一步提出 Congestion Manager，也就是位于终端系统的一项拥塞管理服务。它把有关联的流归入 macroflow，共享拥塞算法和状态，并向应用提供异步调度或同步查询接口。

这并不是把所有数据塞进一个中央队列。真正的新安排，是把“何时可以占用稀缺发送机会”与“这次机会应承载什么内容”分开。管理器了解拥塞窗口与竞争请求；应用了解哪一帧、哪段声音或哪条消息仍然有价值。

请求只声明需求，不提交数据

应用调用 cm_request 时，不会附上一块让 CM 保管的缓冲区。管理器记录的是需求，而不是等待发送的包。因此，它既不检查应用载荷，也不承诺稍后替应用发出某条特定消息。

当共享的拥塞控制与调度器判断可以发送时，CM 调用 cmapp_send。回调给出一个上限，通常是一个 PMTU。应用在最后时刻才选择内容，可以丢弃已经失去价值的旧视频帧，降低编码质量，或者重新分包以适应许可大小。

这种设计利用了双方不同的知识。中央服务可以公平或高效地排列机会，却不必理解媒体语义；应用可以决定内容，却不应独占对路径拥塞状态的解释。数据面与控制面在回调处短暂相遇，但没有合并。

所以，回调记录绝不是发送凭证。收到许可后，应用还可能没有生成包、无法交给 IP、已经崩溃，或发现许可已经过期。若把 cmapp_send 直接统计为流量，就会抹掉 RFC 特意保留的适应空间。

许可会过期，未使用的机会要归还

RFC 3124 为许可设定了寿命：取一个往返时间与实现阈值中的较大者。过期回调不得继续使用。拥塞状态不断变化，旧窗口产生的机会不能变成永久信用。

应用完成尝试后，以 cm_notify(nsent) 报告实际进入 IP 输出路径的字节数。如果没有发送，就应报告零，把未用机会还给调度器。这一套往返账目明确区分了三件事：应用提出需求、控制器批准机会、主机实际使用多少。

规范同时承认应用并不完美。进程可能在报告零之前退出，也可能漏掉通知。CM 必须能从沉默中恢复，不能永远阻塞其他请求。但恢复策略也不能假装每个许可都已用掉，否则控制模型会把虚构的在途字节当成事实。

nsent 的含义只是主机在 IP 输出处送出的数据量，并非对端接收量。来自接收方的证据通过 cm_update 进入，并区分收到、丢失、显式拥塞通知与没有反馈等情形。许可、本机发送、远端观察因此拥有各自的时间戳和证据来源。

Macroflow 是控制假设，不是路径证明

归入同一 macroflow 的流可以共享拥塞算法和状态。应用可以参与分组，因为它可能知道若干会话之间的关系。但共同的组名不会证明所有包经过同一瓶颈。路由会变化，多宿主机器会选择不同接口，分组规则也可能过宽。

要判断分组是否合理，必须把 macroflow 标识与当时的路由、接口、目的地和测量证据一起保存。只留下组名，只能说明某个软件做过一项本地决定，不能把决定升格为路径事实。

这一点也划清了 RFC 3124 与其他历史章节的边界。RFC 2581、RFC 2861 和后来的 RFC 5681 描述 TCP 的拥塞行为，RFC 9040 再次讨论连接间共享传输指标；RFC 3124 独特之处是把请求—许可—通知协议开放给应用，并为跨流的调度提供共同接口，而不要求数据都变成 TCP 的一部分。

“行为良好”是一份合作契约

RFC 把只在 CM 同意后发送、并准确报告全部发送数据的应用称为 well-behaved。这个词描述参与者对接口的遵守，不代表管理器能够阻止主机上的每一个进程绕过它。

文档明确指出，CM 不强制所有应用遵守拥塞行为，也无法保护网络免受被攻陷主机的伤害。若要实施主机 policing 或路由器侧的强制机制，那是另一套控制表面，不在 RFC 3124 的范围内。

因此，发现某台主机安装了 CM，并不能证明所有流量受它调度；发现某应用调用了接口，也不能排除同机的旁路流量。即使应用完全按规范合作，仍需确认真实路由是否符合 macroflow 假设。标准规定了合作方式，却没有制造强制执行能力。

采用本身也是可选的。应用一旦选择使用，就应遵循规范；但标准轨道地位不是部署量、普及率或成功结果的收据。历史叙述必须停在来源可以支持的位置。

无效估算不能伪装成零容量

有些应用希望自己调度，只借用 CM 的测量。同步接口允许它们调用 cm_query，取得速率、RTT 与拥塞估算。若估算无效，返回负值，而不是把未知写成零。

这个小细节体现了一种重要纪律：控制系统必须能够表达“不知道”。未知容量与已测得的零容量会导致完全不同的决策。历史证据也一样，缺少部署收据既不能证明失败，也不能用规范文字代替实际采用。

RFC 2914 给出拥塞控制原则，RFC 2481 记录早期 ECN 实验，RFC 1191 提供路径 MTU 的背景，RFC 8085 后来总结 UDP 责任。这些材料解释 RFC 3124 面对的问题，却都不能证明某个操作系统或应用真实启用了它。

一次发送需要一条完整证据链

若要审计一次决定，应保存 cm_request 的时间、流与 macroflow，调度器状态，回调的大小与时间，RTT、PMTU 和到期计算，应用最终选中的内容，IP 输出处的 cm_notify，接口与路由，以及后续 cm_update。要证明用户看到的结果，还需更下游的测量。

每份记录只回答一个问题。请求说明应用声明过需求；回调说明调度器提供过短时机会；正数通知说明应用报告过本机发送；接收反馈才开始描述路径之后发生的事。任何一个都不能单独代表全部链条。

RFC 3124 的持久价值正在于此。它试图让主机共享拥塞知识，却没有假装共享调度就是共享数据所有权。一次发送许可控制的是时机；它还不是数据包，更不是送达。

一次发送许可还不是一个数据包队列：RFC 3124

为何重要

摘要

同一条瓶颈，主机里却有许多套记忆

请求只声明需求，不提交数据

许可会过期，未使用的机会要归还

Macroflow 是控制假设，不是路径证明

“行为良好”是一份合作契约

无效估算不能伪装成零容量

一次发送需要一条完整证据链

来源

档案背景详情

Strategic Circle

Leadership Alliance

Strategic Circle 专属简报

Leadership Alliance 简报