跳到主要内容

8. 示例 (Examples)

本节通过展示 PRR 和 [RFC6675] 算法在两个示例场景中的不同响应来说明其行为: 一个连接经历单个包丢失, 或者经历连续 15 个包的突发丢失.

测试场景设置​

所有情况都使用:

  • 批量数据传输 (无应用暂停)
  • Reno 拥塞控制 [RFC5681]
  • 初始状态: cwnd = FlightSize = inflight = 20 个段
  • ssthresh: 将在恢复开始时设置为 10
  • 快速重传: 使用标准快速重传 [RFC5681]
  • Limited Transmit [RFC3042]: 响应前三个重复 ACK 发送 2 个新段 + 1 个重传段

图示说明​

下图展示段 0 丢失后第一个往返时间内每个 ACK 的响应. 顶行 ("ack#") 表示触发 ACK 的段编号, X 表示丢失的段.

"cwnd" 和 "inflight" 行展示这些算法在处理每个返回 ACK 后, 但在任何进一步(重)传输之前的 cwnd 和 inflight 值. "sent" 行表示将发送多少个 "N" 新数据或 "R" 重传.

示例 1: 单段丢失​

RFC 6675
a  X  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20 21 22
c 20 20 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10
i 19 19 18 18 17 16 15 14 13 12 11 10  9  9  9  9  9  9  9  9  9  9
s  N  N  R  N  N  N  N  N  N  N  N  N  N

PRR
a  X  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20 21 22
c 20 20 19 18 18 17 17 16 16 15 15 14 14 13 13 12 12 11 11 10 10 10
i 19 19 18 18 17 17 16 16 15 15 14 14 13 13 12 12 11 11 10 10  9  9
s  N  N  R  N  N  N  N  N  N  N  N  N  N

a: ack#; c: cwnd; i: inflight; s: sent

分析​

在第一个示例中:

ACK 序列:

  • ACK #1 到 #19 携带原始 flight 数据的 SACK
  • ACK #20 和 #21 携带由 limited transmit 触发的两个段的 SACK
  • ACK #22 携带覆盖所有数据的完整累计 ACK, 包括 limited transmit
  • ACK #22 完成快速恢复阶段, 因而也完成 PRR 阶段

行为对比:

  • 两种算法发送的数据总量相同
  • 两者完成快速恢复时 cwnd 都匹配 ssthresh, 值为 20
  • RFC 6675 经历了 "半窗口静默"
  • PRR 将自愿窗口降低分布到整个 RTT

示例 2: 15 个段的突发丢失​

接下来考虑具有相同初始条件的示例场景, 但前 15 个包 (0-14) 丢失. 在该有损 RTT 的剩余时间内, 只有 5 个 ACK 返回给发送方. 下面依次考察每种算法.

RFC 6675
a  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X 15 16 17 18 19
c 20 20 10 10 10
i 19 19  4  9  9
s  N  N  6R  R  R

PRR
a  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X 15 16 17 18 19
c 20 20  5  5  5
i 19 19  4  4  4
s  N  N  R  R  R

a: ack#; c: cwnd; i: inflight; s: sent

分析​

在这个特定情形中:

RFC 6675 行为:

  • 一旦快速重传被触发 (在段 17 的 ACK 上), 发送方立即重传足够多的数据, 使 inflight 上升到匹配 cwnd
  • 早期测量 (在 [RFC6675] 第 6 节中讨论) 表明, [RFC6675] 明显优于 [RFC6937] 版本的 PRR (该版本仅使用 PRR-CRB) 以及其他经过测试的类似保守算法
  • 这说明实际丢失超过拥塞控制算法确定的 cwnd 降低量的情况非常常见

PRR 行为:

  • 在快速恢复的第一个 RTT 中, PRR 使用 PRR-CRB 遵循包守恒
  • 由于总丢失使 inflight 保持低于 ssthresh, 已发送数据会使总传输数据 prr_out 跟随返回 ACK 报告为已交付到接收方的总数据
  • 传输由发送限制控制, 该限制设置为 prr_delivered - prr_out

恢复过程:

  • 虽然图中未显示, 但一旦从 ACK #17 开始发送的快速重传被交付, 并引发使 SND.UNA 增加的 ACK, PRR 就会进入 PRR-SSRB
  • 在恢复期间每个 ACK 精确增加 1 个段的窗口, 直到 inflight 在恢复期间上升到 ssthresh
  • 对于 cwnd 较大时的严重丢失, PRR-SSRB 的恢复速度按指数级快于 PRR-CRB
  • 虽然在恢复期间增加窗口可能看似不明智, 但需要记住, 这实际上比 [RFC6675] 允许的行为更保守. [RFC6675] 会响应触发快速重传的 ACK, 以单次突发发送相同数量的额外数据

轻微丢失情形: 对于较不严重的丢失事件, 如果总丢失小于 FlightSize 与 ssthresh 之间的差值, PRR-CRB 和 PRR-SSRB 不会被调用, 因为 PRR 仍处于比例速率降低模式.

最后于 更新