4. RFC 6937からの変更 (Changes Relative to RFC 6937)

[RFC6937]以降の最大の変更は、良好なリカバリ進捗(TCPの場合、最新のACKがSND.UNAを進め、以前の高速再送が損失していないことを示す場合)を使用して削減境界(PRR-CRBまたはPRR-SSRB)を選択する新しいヒューリスティックの導入です。

[RFC6937]は削減境界の選択を実装者の裁量に委ねましたが、デフォルトとしてPRR-SSRBの使用を推奨していました。初期のPRR研究で探索されたすべての環境において、新しいヒューリスティックは古い推奨と一致しています。

SafeACKヒューリスティックの導入

論文「トラフィックポリシングのインターネット全体の分析」[Flach2016policing]は、両方の削減境界が性能が悪いが、異なる理由による、以前に探索されていない重要なケースを発見しました。

トークンバケットポリサーの課題

多くの構成において、トークンバケット・トラフィック・ポリサーは、トークンが枯渇すると、エンドシステムに何の警告もなく、ほとんどのトラフィックを突然ドロップし始める可能性があります。トランスポート輻輳制御は、トークンレートを測定し、以前に観測されたパス性能に基づいてssthreshを設定する機会がありません。このssthresh値は、トークン補充速度よりもはるかに大きいデータ速度につながり、高いパケット損失率を引き起こす可能性があります。

これらの条件下では、両方の削減境界は性能が悪くなります：

• PRR-CRBは過度に保守的 - 必要以上にはるかに小さいウィンドウで非常に長いリカバリになることがある
• PRR-SSRBは過度に攻撃的 - しばしば複数ラウンドの再送損失を引き起こし、両方のケースでリカバリ時間が長引き、アプリケーションのレイテンシまたはスループットに深刻な影響を与える

SafeACK解決策

これらの環境の調査により、削減境界を動的に切り替えるための「SafeACK」ヒューリスティックの開発につながりました：

• デフォルトでPRR-CRBを使用 - リカバリを保守的に開始
• PRR-SSRBに切り替える条件 - ACKがリカバリが順調に進んでいることを示す場合のみ(SND.UNAが進み、新しいパケット損失が検出されない)

SafeACKヒューリスティックは、Googleのコンテンツ配信ネットワーク(CDN)[Flach2016policing]で実験され、2015年以来Linux TCPに実装されています。

適用シナリオ

SafeACKヒューリスティックは以下の場合にのみ呼び出されます：

• パケット損失、アプリケーション制限動作、または他のイベントが現在のインフライトデータ推定をssthresh未満に低下させる
• 高いパケット損失率がヒューリスティックを重要にするが、これはトラフィックポリサー[Flach2016policing]などの深刻なパケット損失がある場合にのみ一般的である
• これらの環境では、ヒューリスティックはいずれかの境界を単独で使用するよりも優れた性能を発揮する