摘要

  • RFC 9937 将 PRR 规定为快速恢复期的发送调节算法：它根据 ACK 所显示的交付、发送端对在途数据的估计，以及拥塞控制算法给出的 ssthresh，计算本端可发送的 SndCnt。
  • 这份额度只回答“此发送端此刻可发多少字节”。它不回答共享瓶颈是否空闲、接收应用是否完成处理、路径是否恢复或客户结果是否成立。

“ACK 又回来了”很容易被压缩成“网络恢复了”。RFC 9937 恰好要求我们不要这样压缩。它在 2025 年 12 月以 Standards Track 发布，取代实验性的 RFC 6937。PRR 的目标是在快速恢复结束时，让实际 flight size 尽量接近拥塞控制算法所定的 ssthresh。目标由控制算法给出，PRR 只负责把发送节奏收敛到那个目标附近。

算法使用的是发送端的最佳估计。DeliveredData 是当前 ACK 所显示的交付量；inflight 是未确认在途字节的估计；RecoverFS 是此恢复期可能交付的数据量估计。发送端再由 SafeACK、恢复计数和这些量导出 SndCnt。高于 ssthresh 时按比例发送；低于时采用保守边界，只有 ACK 显示良好进展时才有限度地放宽。恢复结束时 cwnd 设为 ssthresh，RFC 还特别建议 pacing，因为该步骤可能带来突发。

这是一套值得保留的本地账本，却不是路径账本。SACK 能让核算更准确，但并非前提；不同丢包检测器也可以向 PRR 提供输入。没有 SACK 时，文本还限制异常重复 ACK 虚增交付估计的空间。规格本身已表明：端点依据有限观察进行谨慎调节，并不掌握所有队列、流量监管器、其他流或接收应用的状态。

增量部署只要求改变发送端实现，不要求接收端或网络改动。PRR 可与 Reno 或 CUBIC 协作，而公平性仍由拥塞控制算法决定。于是“本端允许发”不能升级为“共同资源允许我承诺”。

应保存可回放的恢复回执：控制算法和版本、ssthresh、ACK/SACK 和丢包检测输入、各项估计、SndCnt、重传与 pacing 决定、窗口/应用约束，以及恢复后独立测得的结果。亨路的运行中代码优先在此要求很简单：代码可以证明自己算了什么、做了什么，不能把自己的估计命名为全路径事实。

来源