摘要

  • draft-ietf-ccwg-ratelimited-increase-11 拟统一多种传输协议的规则：即使应用供数或接收端流控限制了发送，也允许拥塞窗口增长，但必须受历史最大 FlightSize 约束。
  • 这项上限只规范发送端状态，不能预留未来带宽、打开接收端额度、证明已经采用 pacing，更不能保证随后一批数据能够交付。

一条连接的拥塞窗口可以容纳二十个分段，应用却只交出四个。四个分段全部得到确认，没有观察到丢包，窗口算法甚至还可以增加许可。屏幕上的数字很整齐。

但网络并没有因此替明天的二十四个分段留座。

这正是 IETF 拥塞控制工作组 9 月 6 日发布的 draft-ietf-ccwg-ratelimited-increase-11 所处理的细小而关键的边界。TCP、QUIC、SCTP、DCCP 与 CUBIC 对“窗口未被充分使用时是否增长”给出了不同答案。有的规范干脆停止增长，有的行为可能让窗口持续膨胀，渐渐脱离流量真正验证过的路径能力。新草案选择了中间方案：允许增长，但把增长绑在已经观察到的在途数据上。

这里的“rate-limited”不是说网络已经拥塞，而是发送方没有用尽拥塞控制允许的额度。原因可能是应用暂时没有更多数据，也可能是接收方通过连接或流级流控暂不开放更多 credit。无论哪一种，FlightSize——已经发出但尚未累计确认的数据——都会低于 cwnd。

草案引入 maxFS 作为一段有限记忆：它记录自上一次降低 cwnd 以来出现过的最大 FlightSize。FlightSize 更新时取两者较大值；只要窗口因任何理由下降，maxFS 就归零。之后的窗口增加必须不高于 limit(maxFS)，也就是假设成功发送一个大小为 maxFS 的完整窗口后，该算法依据 ACK 最多会得到的值。慢启动示例的上限是两倍 maxFS，拥塞避免示例则是 maxFS 加一个 SMSS。

这不是把没用掉的额度变成资产。完全不让窗口增长，会让短暂停顿的可变速率应用反复付出重新爬升的延迟；不设上限地增长，又会让 cwnd 远离这条连接实际用过的容量。草案只说：已经确认过的 FlightSize 足以支持有限度的状态增长。它没有说旧窗口中空出来的部分已经被测试。

更重要的是，草案主动承认状态会过期。如果没有额外的窗口衰减机制，maxFS 可以保留很久，最终不再反映当前端到端路径。为此它指向 RFC 7661 的 Congestion Window Validation。RFC 7661 的 pipeACK 统计一个 RTT 及采样期内得到确认的数据量，用来区分近期经过验证的窗口和只反映旧容量的窗口。FlightSize 是一个时点，pipeACK 是一段时间内的观察；两者都不是对未来的可转让权利。

三个控制权必须拆开。应用决定有没有字节可发；接收方决定愿意接收多少连接或流数据；拥塞控制根据网络反馈限制发送方可以注入多少。较高的 cwnd 不会创造业务需求，不能越过接收方背压，也无法保证当前路由上有一段空队列。把三个数字合成“可用吞吐量”，恰恰抹掉了它们分别存在的理由。

pacing 也不能被窗口数值替代。发送端可能获准维持更多在途数据，却仍要把数据包分散到时间轴上，避免瞬时突发。草案说明 maxFS 约束不妨碍 pacing，但没有替具体实现证明 pacing 已启用、间隔合理，或网卡 offload 没有重新形成包列。这需要实现记录与线上数据包证据。

ACK 的含义同样有限。它按某种传输协议的规则记录先前数据的接收情况，并据此更新丢包恢复与拥塞状态。它不能证明路由没有改变、竞争流量不存在、policer 不会触发、接收端 credit 即将扩大，或应用会接受下一件对象。加密认证可以提高“谁发出了 ACK”的可信度，却仍不能让 ACK 代表未来网络。

草案覆盖面很广，法律地位却应被准确描述：若获批准，它将更新 RFC 4341、5681、9002、9260 与 9438；目前仍是可能变化的 Internet-Draft，也不请求 IANA 动作。标准推进、代码实现、功能启用和生产效果需要四份不同证据。

来源