跳到主要内容

4. 相对于 RFC 6937 的变更

相对于 [RFC6937] 最大的变更是引入了新的启发式方法. 该方法利用良好的恢复进展来选择降低边界 (PRR-CRB 或 PRR-SSRB). 对 TCP 而言, 良好恢复进展指最新 ACK 推进了 SND.UNA, 且未表明先前的快速重传已丢失.

[RFC6937] 将降低边界的选择留给实现者自行决定, 但建议默认使用 PRR-SSRB. 对于早期 PRR 研究探索过的所有环境, 新启发式方法与旧建议一致.

SafeACK 启发式方法的引入​

论文 "Internet-Wide Analysis of Traffic Policing" [Flach2016policing] 发现了一个此前未被探索的关键情形: 两种降低边界都会表现不佳, 但原因不同.

令牌桶管制器的挑战​

在许多配置中, 当令牌耗尽时, 令牌桶流量管制器可能会在不给端系统任何警告的情况下突然开始丢弃大部分流量. 传输拥塞控制没有机会测量令牌速率, 也无法根据此前观察到的路径性能设置 ssthresh. 该 ssthresh 值可能导致数据速率远高于令牌补充速率, 从而造成高丢包率.

在这些条件下, 两种降低边界都会表现不佳:

  • PRR-CRB 过于保守 - 有时会在远小于必要值的窗口下产生很长的恢复时间
  • PRR-SSRB 过于激进 - 经常导致多轮重传丢失; 这两种情况都会延长恢复时间, 严重影响应用延迟和/或吞吐量

SafeACK 解决方案​

对这些环境的研究促成了 "SafeACK" 启发式方法, 用于动态切换降低边界:

  • 默认使用 PRR-CRB - 以保守方式开始恢复
  • 切换到 PRR-SSRB 的条件 - 仅当 ACK 表明恢复进展良好时切换, 即 SND.UNA 前进且未检测到新的丢包

SafeACK 启发式方法曾在 Google 的内容分发网络 (CDN) [Flach2016policing] 中进行实验, 并自 2015 年起在 Linux TCP 中实现.

应用场景​

SafeACK 启发式方法仅在以下情况下被调用:

  • 丢包, 应用受限行为或其他事件导致当前 inflight 数据估计值低于 ssthresh
  • 高丢包率使该启发式方法变得关键, 这通常只在存在严重丢包时常见, 例如流量管制器场景 [Flach2016policing]
  • 在这些环境中, 该启发式方法优于单独使用任一边界
最后于 更新