メインコンテンツまでスキップ

8. 例(Examples)

本セクションでは、2つのシナリオ例に対する応答の違いを示すことで、PRRアルゴリズムと[RFC6675]アルゴリズムの動作を説明します：単一のパケット損失を経験する接続と、15個の連続したパケット損失のバーストです。

テストシナリオのセットアップ​

すべてのケースで使用される条件：

  • バルクデータ転送(アプリケーションの停止なし)
  • Reno輻輳制御 [RFC5681]
  • 初期状態: cwnd = FlightSize = inflight = 20セグメント
  • ssthresh: リカバリの開始時に10に設定
  • 高速再送: 標準的な高速再送を使用 [RFC5681]
  • Limited Transmit [RFC3042]: 最初の3つの重複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は、limited transmitによってトリガーされた2つのセグメントのSACKを伝送
  • ACK #22は、すべてのデータ(limited transmitを含む)をカバーする完全な累積ACKを伝送
  • 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未満に保つため、送信されるデータは、返されるACKによって受信者に配信されたと報告された総データにprr_outが従うようにする
  • 送信はprr_delivered - prr_outに設定された送信制限によって制御される

リカバリプロセス：

  • 図には示されていないが、ACK #17から始まる高速再送が配信され、SND.UNAを増加させるACKを引き起こすと、PRRはPRR-SSRBに入る
  • リカバリ中にinflightがssthreshに達するまで、リカバリ中にACKごとに正確に1セグメントずつウィンドウを増加
  • cwndが大きい場合の深刻な損失に対して、PRR-SSRBはPRR-CRBよりも指数関数的に高速にリカバリ
  • リカバリ中にウィンドウを増加させることは賢明ではないように見えるかもしれないが、これは実際には[RFC6675]が許可するものよりも保守的であることを覚えておくことが重要で、[RFC6675]は高速再送をトリガーしたACKに応答して同じ量の追加データを単一のバーストとして送信

軽度の損失ケース： 総損失がFlightSizeとssthreshの差よりも少ない、より軽度の損失イベントの場合、PRRは比例速度削減モードのままであるため、PRR-CRBおよびPRR-SSRBは呼び出されません。

に最終更新