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

7. 特性 (Properties)

以下の特性は、特に記載がない限り、PRR-CRBとPRR-SSRBの両方に共通です:

1. ACKクロックの維持​

PRRは、バースト損失を含むリカバリイベント全体で送信者のACKクロックを維持しようとします。対照的に、[RFC6675]はバースト損失後に大きな、クロック化されていないバーストを送信する可能性があります。

利点: ネットワークに追加のバーストトラフィックを導入することを回避し、輻輳制御の安定化に役立ちます。

2. スムーズなウィンドウ削減​

通常、PRRは自発的ウィンドウ削減を完全なRTT全体に均等に分散します。これには、インターネットトラフィックのバースト性を一般的に減少させる可能性があり、ソフトペーシングの一形態と考えることができます。

仮説的には、任意のペーシングは異なるフローがインターリーブされる確率を増加させ、ACK圧縮やトラフィックのバースト性を増加させる他の現象の機会を減少させます。しかし、これらの効果は定量化されていません。

3. 目標ウィンドウへの正確な収束​

損失が最小限である場合、PRRは輻輳制御アルゴリズムによって選択された目標ウィンドウに正確に収束します。送信者がリカバリの終わりに近づくと、prr_deliveredはRecoverFSに近づき、SndCntはprr_outがssthreshに近づくように計算されることに注意してください。

数学的保証: 理想的な条件下では、リカバリの終わりにinflight = ssthreshとなります。

4. 暗黙的ウィンドウ削減への自動適応​

リカバリ中の複数の孤立した損失による暗黙的ウィンドウ削減は、後続の自発的削減をスキップさせます。少数の損失の場合、ウィンドウサイズは最終的に輻輳制御アルゴリズムによって選択されたウィンドウに正確に到達します。

メカニズム: PRRは自動的に調整し、実際の損失と自発的削減の合計が目標削減に達するようにします。

5. バースト損失の処理​

バースト損失の場合、初期の自発的ウィンドウ削減は、リカバリ中に後から到着するACKに応答して追加のセグメントを送信することによって取り消すことができます。一部の自発的ウィンドウ削減が取り消されず、アプリケーション停止がない限り、inflightの最終値はssthreshと同じになることに注意してください。

柔軟性: 深刻な輻輳が検出されたときにより保守的になり、状況が改善したときにより攻撃的になることを許可します。

6. アプリケーション停止の処理​

いずれかの削減境界を使用するPRRは、アプリケーション停止がある場合の状況を改善します。例えば、送信アプリケーションが送信のためにデータを十分に速くキューに入れない場合、または受信者が受信ウィンドウを前進させるのを停止する場合です。

停止シナリオの処理​

リカバリの初期にアプリケーション停止が発生した場合:

  • prr_outはSndCntによって許可される送信の合計より遅れます
  • 停止による送信機会の逸失は、バンクされた自発的ウィンドウ削減のように扱われます
  • 具体的には、prr_delivered - prr_outを著しく正にします

キャッチアップメカニズム​

送信者がまだリカバリ中にアプリケーションが追いつく場合:

  • 送信者は部分的なウィンドウバーストを送信してinflightを増加させます
  • これにより、inflightはアプリケーションが停止しなかった場合の正確な位置に近づきます
  • このようなバーストは、特定のフローまたはパスを共有する他のフローに有害である可能性がありますが、これはリカバリ中でないときの部分RTTアプリケーション停止で発生することと正確に同じです

統一された動作: PRRは、すべての状態で部分RTT停止動作を統一します。この動作の変更は本文書の範囲外です。

7. インフライト推定器エラーへの堅牢性​

削減境界を使用するPRRは、インフライト推定器のエラーに対してあまり敏感ではありません。

リカバリ中、inflightは基本的に推定器であり、不完全な情報を使用して、未SACKedセグメントが実際に失われているか、単にネットワーク内で順序外であるかを推定します。一部の条件下では、inflightに重大なエラーがある可能性があります。例えば、並べ替えられたデータのバーストが早期に失われたと仮定され、再送信用にマークされた場合、inflightは過小評価されます。

エラー許容メカニズム​

送信がinflightによって直接調整される場合 ([RFC6675]のように):

  • inflight推定器のステップ不連続性がデータのバーストを引き起こします
  • 数ACK後にinflight推定器が修正されると、バーストは撤回できません

PRRダイナミクスでは:

  • inflightは、DeliveredDataからSndCntを計算するためにどのアルゴリズム (PRRまたは削減境界) を使用するかを決定するだけです
  • inflightが過小評価されている場合、アルゴリズムはACKごとに最大1セグメント異なります
  • inflightが更新されると、リカバリの終わりに同じ最終ウィンドウに収束します

8. 強いパケット保存境界 (PRR-CRB)​

リカバリ中のすべての条件とイベントのシーケンスの下で、PRR-CRBは送信されるデータを受信者に配信されたデータ量以下に厳密に制限します。この強いパケット保存境界は、一部の環境で追加の強制損失につながらない最も攻撃的なアルゴリズムです。

キュー長の特性​

これには、クロストラフィックのないボトルネックに待機キューがある場合、パケットの到着時刻と出発時刻の差異による+1/-1の変動を除いて、リカバリ中にキューが完全に一定の長さを維持するという特性があります。

この特性の詳細な議論については、付録Aを参照してください。

9. PRR-SSRBのトレードオフ​

強いパケット保存境界は多くの理由で非常に魅力的ですが、以前の測定 ([RFC6675]のセクション6で議論されている) は、それが十分に攻撃的ではなく、バースト損失の存在下でデータバーストを許可する[RFC6675]で説明されているアルゴリズムほど良好に機能しないことを示唆しています。

PRR-SSRBは、ACKがさらなる損失なしでリカバリが順調に進行していることを示す場合に、パケット保存境界に対してACKごとに1つの追加セグメントを送信することを接続に許可する妥協案です。

パフォーマンスバランス​

厳密なパケット保存境界の観点から:

  • PRR-SSRBはリカバリ中にウィンドウを開きます
  • しかし、バースト損失の存在下では[RFC6675]よりもはるかに攻撃的ではありません
  • リカバリ中の追加損失の確率が低いため、後者を上回ります

実用的な効果: PRR-SSRBは、良好なパフォーマンスを維持しながら、[RFC6675]よりも優れた安定性を提供します。

に最終更新