9. PRRを他のトランスポートプロトコルへ適応
主要なPRRアルゴリズムと削減境界は、[RFC6675]をサポートできる任意のトランスポートプロトコルに適応できます。主要な実装の1つ(Linux TCP)では、PRRは2011年の導入以来、デフォルトおよびサポートされている輻輳制御モジュールの高速リカバリアルゴリズムとなっています[First_TCP_PRR]。
SafeACKヒューリスティックは、他のセグメントが再送のためにマークされることを引き起こさない再送のACKに一般化できます。
10. 測定研究 (Measurement Studies)
[RFC6937]について、付随論文[IMC11]は大規模測定研究で[RFC3517]および様々な実験的PRRバージョンを評価しました。発行時点で、研究で使用されたレガシーアルゴリズムは研究で使用されたコードベースに存在しなくなり、歴史的アルゴリズムを再作成せずにこのような比較を行うことが困難になりました。
測定研究に興味がある読者は、[RFC6937]のセクション5とIMC論文[IMC11]を参照してください。
11. 運用上の考慮事項 (Operational Considerations)
11.1. 増分展開 (Incremental Deployment)
PRRは増分的に展開可能です。なぜなら、データ配信を確認し、失われたデータを検出するために既存のトランスポートプロトコルメカニズムのみを利用するからです。
展開要件:
- PRRはデータ送信者のトランスポートプロトコル実装の変更のみを必要とします
- データ受信者への変更は必要ありません
- ネットワークへの変更は必要ありません
これにより、PRRを使用するデータ送信者は、既存のデータ受信者またはネットワークと正しく動作します。PRRは、ルーター、スイッチ、またはネットワーク内の他のデバイスからの変更や支援を必要としません。
11.2. 公平性 (Fairness)
PRRは、それが展開される輻輳制御アルゴリズムの公平性プロパティを維持することを目指します。
動作方法:
- PRRは、輻輳制御応答フェーズ(高速リカバリまたは[RFC3168]で定義されたTCP ECN反応からのcwndステップ削減など)中にのみ実行されます
- 調整フェーズ中のインフライトデータ量を滑らかに調整するために、短期的な確認ごとの決定のみを行います
- フェーズの終わりに、輻輳制御アルゴリズムによって決定されたスロースタート閾値(ssthresh)にできるだけ近づくようにします
変更されないメカニズム:
- PRRは、輻輳制御応答フェーズ外の輻輳制御cwnd増加または減少メカニズムを変更しません
11.3. 過度なキューイングとパケット損失からのネットワーク保護
長期的影響
長期的な時間スケールでは、PRRは、それが展開される輻輳制御アルゴリズムのキューイングおよびパケット損失プロパティを維持することを目指します。
上記のように、PRRは輻輳制御応答フェーズ(高速リカバリまたはECNへの応答など)中にのみ実行され、調整フェーズ中のインフライトデータ量を滑らかに調整するために短期的な確認ごとの決定のみを行い、フェーズの終わりに輻輳制御アルゴリズムによって決定されたスロースタート閾値(ssthresh)にできるだけ近づくようにします。
短期的影響
短期的な時間スケールでは、PRRは[RFC6675]のような先行アプローチよりも低いパケット損失率をもたらすことを目指します。
利点の原則:
- PRRはパケット保存の原則に触発されています
- 可能な限り自己クロックプロセスに依存します
- [RFC6675]では、SACKオプションを運び、大量の欠落データを暗示する単一のACKがパイプ推定器にステップ不連続性を引き起こす可能性があります
- これにより、高速再送が配信されたデータ量をはるかに超える大量のデータのバーストを送信する可能性があります
- PRRは、失われたデータ量ではなく配信されたデータ量に基づいて送信決定を行うことにより、このようなバーストを回避します
性能改善:
- 上記のように、PRR-SSRBは[RFC6675]よりも攻撃的ではありません(より少ないセグメントを送信するか、それらを送信するのにより多くの時間がかかる)
- リカバリ中の追加パケット損失の確率が低いため、後者よりも優れた性能を発揮します
12. IANAに関する考慮事項 (IANA Considerations)
この文書にはIANAアクションはありません。
13. セキュリティに関する考慮事項 (Security Considerations)
PRRは、トランスポートプロトコルのリスクプロファイルを変更しません。
ACK分割攻撃からの保護:
PRRをバイトカウントからセグメントカウントに適応させる実装者は、ACK分割攻撃[Savage99]の影響に注意する必要があります。これは、受信者が送信者の輻輳アカウンティングを混乱させることを意図して部分的なセグメントを確認するものです。
推奨事項: セグメントカウントではなくバイトカウントを使用することで、このような攻撃に対してより良く防御できます。