Skip to main content

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包含原始数据飞行的SACK
  • ACK#20和#21携带前两个SACKed段触发的limited transmit的SACK
  • ACK#22携带覆盖所有数据(包括limited transmit)的完整累积ACK
  • ACK#22完成快速恢复阶段,从而完成PRR阶段

行为对比:

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

示例2: 15段突发丢包​

接下来,考虑具有相同初始条件的示例场景,除了前15个数据包(0-14)丢失。在丢包往返的剩余时间内,只有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行为:

  • 在快速恢复的第一个往返期间,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]允许的要保守,后者在触发快速重传的ACK响应中作为单个突发发送相同数量的额外数据

轻度丢包情况: 对于不太严重的丢包事件,其中总丢包小于FlightSize和ssthresh之间的差异,不会调用PRR-CRB和PRR-SSRB,因为PRR保持在比例速率降低模式。

Last updated on