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

5. 他の標準との関係 (Relationships to Other Standards)

PRRは、ほぼ1ラウンドトリップ時間のタイムスケールで送信レートに乗法的削減を適用することを意図し、現在のインフライトデータ量が輻輳ウィンドウ(cwnd)によって制限され、その削減中のターゲットインフライトデータ量がssthreshによって与えられる固定値である、任意の輻輳制御アルゴリズムと組み合わせて使用できます。

特に、PRRはReno [RFC5681]およびCUBIC [RFC9438]輻輳制御での使用に適しています。

損失回復アルゴリズムとの関係​

PRRは「SACKベースTCPのための保守的な損失回復アルゴリズム」[RFC6675]の修正として記述されています。SACK [RFC2018]と共に使用すると最も正確ですが、SACKは必須ではありません。

PRRは幅広い損失検出アルゴリズムと組み合わせることができます。これは、PRRが損失検出アルゴリズムがどのパケットが配信されどのパケットが損失したかを推定する方法の詳細に依存しないためです。各ACKを受信すると、PRRは損失検出アルゴリズムから、損失としてマークされたパケット数と配信されたとしてマークされたパケット数を通信してもらうだけで済みます。

したがって、PRRは以下の文書で指定または記述されている損失検出アルゴリズムと組み合わせることができます：

  • Reno [RFC5681]
  • NewReno [RFC6582]
  • SACK [RFC6675]
  • Forward Acknowledgment (FACK) [FACK]
  • Recent Acknowledgment Tail Loss Probe (RACK-TLP) [RFC8985]

RACK-TLPの性能特性、テール損失、再順序付け、および損失した再送に対する弾力性を含むため、PRRをRACK-TLP損失回復[RFC8985]と共に実装することが推奨されます。

SafeACKヒューリスティックの起源​

SafeACKヒューリスティックは、[RFC8985]の初期の前身で堅牢な損失再送検出を開発した結果でした。

損失再送検出がない場合、非常に高いパケット損失率を引き起こすポリサーは、再送タイムアウトを引き起こす極めて高いリスクに直面しました。なぜなら、Reno [RFC5681]、CUBIC [RFC9438]、および[RFC6675]はポリシング速度をはるかに超える再送を送信する可能性があったためです。

輻輳制御アルゴリズムとの互換性​

PRRは様々な輻輳制御アルゴリズムとうまく機能するように設計されています：

Reno輻輳制御​

  • PRRはRenoの高速リカバリプロセスを滑らかにします
  • リカバリ開始時のRenoの急激なウィンドウ削減を回避
  • より安定した送信レートを提供

CUBIC輻輳制御​

  • PRRはCUBICのウィンドウ削減メカニズムと互換性があります
  • 高速リカバリ中に正確なレート制御を提供
  • リカバリ後のCUBICの成長特性を維持

ECN互換性​

PRRは、明示的輻輳通知(ECN)[RFC3168]で使用するために適応できます。これは、実際のパケット損失ではなくECNマーキングに応答してPRR処理を呼び出すために、損失回復状態機械の一部を使用することによって行われます。

トランスポートプロトコルとの互換性​

PRRは元々TCPのために設計されましたが、その中核原理は他のトランスポートプロトコルに適用できます。ただし、これらのプロトコルが以下を満たす必要があります：

  1. ウィンドウベースの輻輳制御を使用
  2. 高速リカバリに似たメカニズムを持つ
  3. インフライトデータ量を推定できる
  4. 送信されたデータの確認応答を受信

第9章では、PRRを他のトランスポートプロトコルに適応させるための考慮事項を詳細に議論します。

に最終更新