6. 共通パケット化プロパティ

このセクションでは、PLPMTUDを実装するために必要な一般的なパケット化層のプロパティと特性について説明します。また、すべてのパケット化層に共通するいくつかの実装上の問題についても説明します。

6.1. 損失検出メカニズム

パケット化層が損失を検出および報告するためのタイムリーで堅牢なメカニズムを持つことが重要です。PLPMTUDは検出された損失に基づいてMTU調整を行います。損失通知の遅延または不正確さは、不正なMTU決定または遅い収束をもたらす可能性があります。メカニズムがプローブの孤立した損失とプローブの前方および後方ウィンドウの他の損失を確実に区別できることが重要です。

パケット化プロトコルが選択的確認応答(SACK)スコアボード[RFC3517]やACKベクター[RFC4340]などの明示的な損失検出メカニズムを使用して、実際の損失と再順序付けされたデータを区別する場合が最適ですが、TCP Renoスタイルの重複確認応答カウントなどの暗黙的なメカニズムで十分です。

PLPMTUDは、損失回復の主要なメカニズムとしてタイムアウトに依存するプロトコルでも実装できます。ただし、他に代替手段がない限り、タイムアウトを損失指示の主要なメカニズムとして使用すべきではありません(SHOULD NOT)。

6.2. プローブの生成

パケット化層を変更してプローブを生成する方法はいくつかあります。異なる技術は3つの領域で異なるオーバーヘッドを招きます:プローブパケットの生成の難しさ(パケット化層の実装の複雑さと追加のデータ移動の観点から)、プローブによって消費される可能性のある追加のネットワーク容量、失敗したプローブから回復するオーバーヘッド(ネットワークとプロトコルの両方のオーバーヘッド)。

一部のプロトコルは、ダミーデータでの任意のパディングを許可するように拡張される可能性があります。これにより、上位層からの参加なしにプローブを実行でき、プローブが失敗した場合、欠落データ(「プローブギャップ」)が再送信時に現在のMTU内に収まることが保証されるため、実装が大幅に簡素化されます。

多くのパケット化層プロトコルは、任意の長さにパディングできる純粋な制御メッセージ(上位プロトコル層からのデータなし)を運ぶことができます。たとえば、SCTP PADチャンクをこの方法で使用できます(セクション10.2を参照)。このアプローチには、プローブが失われた場合に何も再送信する必要がないという利点があります。

これらの技術はTCPでは機能しません。なぜなら、パディングと実際のペイロードデータを区別するための個別の長さフィールドや他のメカニズムがないからです。TCPの唯一のアプローチは、超過サイズのセグメントで追加のペイロードデータを送信することです。

いくつかのケースでは、パケット化層プロトコル自体内でプローブを生成する合理的なメカニズムがない場合があります。最後の手段として、プローブパケットを送信するためにICMP ECHO(「ping」)などの補助プロトコルに依存することが可能な場合があります。