跳到主要内容

9. 将 PRR 适配到其他传输协议

PRR 主算法和降低边界可适配到任何能够支持 [RFC6675] 的传输协议. 在一个主要实现 (Linux TCP) 中, 自 2011 年引入 PRR 以来 [First_TCP_PRR], PRR 一直是其默认和受支持拥塞控制模块的快速恢复算法.

SafeACK 启发式方法可以泛化到任何不会导致其他段被标记为重传的重传 ACK.

10. 测量研究

对于 [RFC6937], 一篇配套论文 [IMC11] 在大规模测量研究中评估了 [RFC3517] 和多个实验版本的 PRR. 在本文档发布时, 研究中使用的遗留算法已经不存在于该研究所用代码库中, 因此如果不重建历史算法, 很难进行此类比较.

对测量研究感兴趣的读者应查阅 [RFC6937] 第 5 节和 IMC 论文 [IMC11].

11. 运行考虑

11.1. 增量部署​

PRR 可以增量部署, 因为它只利用现有传输协议机制来确认数据交付并检测丢失数据.

部署要求:

  • PRR 只需要修改数据发送方的传输协议实现
  • 不需要修改数据接收方
  • 不需要修改网络

这使使用 PRR 的数据发送方能够与任何现有数据接收方或网络正确协同工作. PRR 不要求网络中的路由器, 交换机或其他设备做出任何改变或提供任何协助.

11.2. 公平性​

PRR 旨在维持其所部署拥塞控制算法的公平性属性.

工作方式:

  • PRR 只在拥塞控制响应阶段运行, 例如快速恢复, 或 [RFC3168] 中定义的 TCP ECN 反应导致的 cwnd 阶跃降低
  • 在调节阶段只做短期的, 逐确认的决策, 以平滑调节 inflight 数据量
  • 使其在该阶段结束时尽可能接近拥塞控制算法确定的慢启动阈值 (ssthresh)

未修改的机制:

  • PRR 不修改拥塞控制响应阶段之外的拥塞控制 cwnd 增加或降低机制

11.3. 保护网络免受过度排队和丢包影响​

长期影响​

在较长时间尺度上, PRR 旨在维持其所部署拥塞控制算法的排队和丢包属性.

如上所述, PRR 只在拥塞控制响应阶段运行, 例如快速恢复或响应 ECN. 它在调节阶段只做短期的, 逐确认的决策, 以平滑调节 inflight 数据量, 使其在该阶段结束时尽可能接近拥塞控制算法确定的慢启动阈值 (ssthresh).

短期影响​

在较短时间尺度上, PRR 旨在实现比 [RFC6675] 等先前方法更低的丢包率.

优势原则:

  • PRR 受包守恒原则启发
  • 尽可能依赖自时钟过程
  • 使用 [RFC6675] 时, 单个携带 SACK 选项且暗示大量数据缺失的 ACK 可能导致 pipe 估计器出现阶跃不连续
  • 这可能导致快速重传发送远超已交付数据量的大量突发数据
  • PRR 基于已交付数据量而非丢失数据量做出传输决策, 从而避免此类突发

性能改进:

  • 如上所述, PRR-SSRB 没有 [RFC6675] 激进, 即发送更少段或花费更多时间发送这些段
  • 由于恢复期间发生额外丢包的概率更低, 它的表现优于后者

12. IANA 考虑

本文档没有 IANA 操作.

13. 安全考虑

PRR 不改变传输协议的风险特征.

ACK 分割攻击防护:

将 PRR 从按字节计数适配为按段计数的实现者, 必须注意 ACK 分割攻击 [Savage99] 的影响. 在这种攻击中, 接收方确认部分段, 目的是混淆发送方的拥塞记账.

建议: 使用字节计数而不是段计数可以更好地防御此类攻击.

最后于 更新