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

10. 特定のパケット化レイヤー

すべてのパケット化レイヤープロトコルは、セクション6で説明されているすべての問題を考慮する必要があります。多くのプロトコルでは、これらの問題に対処することは簡単です。このセクションでは、いくつかのプロトコルでPLPMTUDを実装するための具体的な詳細について説明します。ここでの説明が、実装者が追加のプロトコルに適応するのに十分な例示となることが期待されます。

10.1. TCPを使用したプロービング方法​

TCPには、インバンドデータとパディングを区別するメカニズムがありません。したがって、TCPはデータを適切にセグメント化することでプローブを生成する必要があります。セグメント化には、オーバーラップとノンオーバーラップの2つのアプローチがあります。

ノンオーバーラップ方法​

ノンオーバーラップ方法では、プローブとその後のセグメントにオーバーラップするデータが含まれないようにデータがセグメント化されます。プローブが失われた場合、「プローブギャップ」はヘッダーを除いた完全なプローブサイズになります。プローブギャップ内のデータは、複数の小さなセグメントで再送信する必要があります。

TCPシーケンス番号

t   <---->
i         <-------->           (プローブ)
m                   <---->
e
                .
                .                (プローブ失われる)
                .

            <---->               (プローブギャップ再送信)
                  <-->

オーバーラップ方法​

代替アプローチは、プローブギャップの長さが現在のMSSと等しくなるように、プローブとオーバーラップする後続データを送信することです。プローブが成功した場合、これはいくつかのデータを2回送信するという追加のオーバーヘッドがありますが、失われたプローブの後に1つのセグメントのみを再送信する必要があります。プローブが成功すると、送信された重複データのために重複確認応答が生成される可能性があります。これらの重複確認応答がFast Retransmitをトリガーしないことが重要です。したがって、このアプローチを使用する実装は、プローブサイズを現在のMSSの3倍に制限する(最大2つの重複確認応答を引き起こす)か、成功したプローブの直後のデータに対して重複確認応答しきい値を適切に調整すべきです(SHOULD)。

TCPシーケンス番号

t   <---->
i         <-------->           (プローブ)
m               <---->
e                     <---->

                .
                .                (プローブ失われる)
                .

            <---->               (プローブギャップ再送信)

使用するセグメント化方法の選択は、特定のTCP実装にとって最も簡単で効率的なものに基づくべきです。

10.2. SCTPを使用したプロービング方法​

Stream Control Transmission Protocol (SCTP) [RFC2960]では、アプリケーションがメッセージをSCTPに書き込み、SCTPがデータをネットワークを通じて送信するのに適したより小さな「チャンク」に分割します。各チャンクにはTransmission Sequence Number (TSN)が割り当てられます。TSNが送信されると、SCTPはチャンクサイズを変更できません。SCTPマルチパスサポートは通常、SCTPがすべてのパスの最小PMTUに収まるようにチャンクサイズを選択することを要求します。必須ではありませんが、実装は、より大きなPMTUを持つパスで送信するより大きなIPパケットを作成するために、複数のデータチャンクをバンドルすることができます。SCTPは、ピアへの各パスで独立してPMTUをプローブする必要があることに注意してください。

プローブを生成するための推奨される方法は、パディングのみで構成されるチャンクをSCTPメッセージに追加することです。[RFC4820]で定義されているPADチャンクを最小長のHEARTBEAT (HB)チャンクに付加してプローブパケットを構築すべきです(SHOULD)。この方法は、すべての現在のSCTP実装と完全に互換性があります。

SCTPは、インラインデータを使用して、上記で説明したTCPと同様の方法でプローブすることもできます(MAY)。このような方法を使用すると、成功したプローブに追加のオーバーヘッドがないという利点がありますが、失敗したプローブはデータの再送信を必要とし、フローのパフォーマンスに影響を与える可能性があります。

10.3. IP断片化のプロービング方法​

通常、大きなデータグラムを送信し、IP断片化に依存してそれらを配信するプロトコルとアプリケーションがいくつかあります。これには望ましくない結果があることが長い間知られています[Kent87]。最近では、IPv4断片化が今日のインターネットでの一般的な使用には十分に堅牢ではないことが明らかになっています。16ビットのIP識別フィールドは、頻繁に誤って関連付けられたIPフラグメントを防ぐのに十分な大きさではなく、TCPとUDPのチェックサムは、結果として生じる破損したデータが上位プロトコル層に配信されるのを防ぐのに不十分です[frag-errors]。

セクション8で述べたように、データグラムプロトコル(UDPなど)はパケット化レイヤーとしてIP断片化に依存する可能性があります。ただし、PLPMTUDを実装するためにIP断片化を使用することは問題があります。IP層には、アプリケーションの直接参加なしに、パケットが最終的に遠方のノードに配信されたかどうかを判断するメカニズムがないためです。

変更されていないアプリケーションの下でパケット化レイヤーとしてIP断片化をサポートするには、実装はセクション5.2で説明されているパスMTU共有と、パスMTUをプローブするための補助プロトコルに依存すべきです(SHOULD)。ICMP ECHOとECHO REPLY、またはICMPメッセージをトリガーする「traceroute」スタイルのUDPデータグラムなど、この目的に使用できるプロトコルがいくつかあります。ICMP ECHOとECHO REPLYの使用は、フォワードパスとリターンパスの両方をプローブするため、送信者は2つの最小値のみを利用できます。利用可能な場合は、フォワードパスのみをプローブする他の方法が推奨されます。

これらのアプローチにはすべて、いくつかの潜在的な堅牢性の問題があります。最も可能性の高い失敗は、MTUに関係のない損失(たとえば、特定のプロトコルタイプを破棄するノード)によるものです。これらのMTUに関係のない損失は、PLPMTUDがMTUを引き上げることを妨げ、IP断片化が必要以上に小さいMTUを使用することを強制する可能性があります。これらの失敗は相互運用性の問題を引き起こす可能性が低いため、比較的無害です。

ただし、中間ボックスや、異なるプロトコルタイプまたはセッションに対して異なるパスを選択する上位レイヤールーターによって引き起こされる可能性があるなど、他のより深刻な失敗モードが存在します。このような環境では、補助プロトコルは主要なプロトコルとは異なるパスMTUを合法的に経験する可能性があります。補助プロトコルが主要なプロトコルよりも大きいMTUを見つけた場合、PLPMTUDは主要なプロトコルで使用できないMTUを選択する可能性があります。これは潜在的に深刻な問題ですが、この種の状況は多数のオブザーバーによって正しくないと見なされる可能性が高く、したがってそれを修正する強い動機があります。

コネクションレスプロトコルは、MTUブラックホールを効果的に診断するのに十分な状態を保持しない可能性があるため、パスをプローブしてMTUを測定する前に、小さすぎる初期MTU(たとえば、1 kByte以下)を使用する側に誤る方がより堅牢です。このため、IP断片化を使用する実装は、セクション7.2で説明されているように選択される初期eff_pmtuを使用すべきですが(SHOULD)、コネクションレスプロトコルのデフォルトの初期eff_mtuに別個のグローバル制御を使用します。

コネクションレスプロトコルは、パス情報キャッシュの維持に関して追加の問題も導入します。接続の確立と切断に対応するイベントがなく、キャッシュ自体を管理するために使用できません。自然なアプローチは、「デフォルトパス」の不変キャッシュエントリを保持することです。これは、コネクションレスプロトコルの初期値に固定されたeff_pmtuを持ちます。補助パスMTU検出プロトコルは、特定の宛先への断片化されたデータグラムの数が設定可能なしきい値(たとえば、5つのデータグラム)に達すると呼び出されます。補助プロトコルがeff_pmtuを更新すると新しいパスキャッシュエントリが作成され、タイマーまたはLeast Recently Usedキャッシュ置換アルゴリズムに基づいて削除されます。

10.4. アプリケーションを使用したプロービング方法​

IP断片化と補助プロトコルに依存してパスMTU検出を実行することの欠点は、アプリケーション自体内で、アプリケーション独自のプロトコルを使用してパスMTU検出を実装することで克服できます。アプリケーションには、プローブを生成するための適切な方法があり、プローブが失われたかどうかを判断するための正確でタイムリーなメカニズムが必要です。

理想的には、アプリケーションプロトコルには、メッセージ配信を確認する軽量エコー機能と、パディングがエコーされないように、メッセージを目的のプローブサイズまでパディングするメカニズムが含まれます。この組み合わせ(SCTP HBとPADに似ている)は、アプリケーションが非対称MTUを持つパス上の各方向のMTUを個別に測定できるため、推奨されます(RECOMMENDED)。

「エコープラスパッド」でPLPMTUDを実装できないプロトコルには、プローブを生成するための代替方法がよくあります。たとえば、プロトコルには、フォワードパスとリターンパスの最小MTUを効果的に測定する可変長エコーがある場合や、実際のアプリケーションデータを運ぶ通常のメッセージにパディングを追加する方法がある場合があります。アプリケーションデータをセグメント化してプローブを生成する代替方法もある可能性があり、最後の手段として、MTU検出を特にサポートするために新しいメッセージタイプでプロトコルを拡張することが実行可能な場合があります。

PLPMTUDをサポートするために新しいメッセージタイプを追加する必要がある場合、最も一般的なアプローチは、ECHOとPADメッセージを追加することです。これにより、アプリケーション固有のPLPMTUD実装が同じエンドシステム上の他のアプリケーションとプロトコルとどのように相互作用するかについて、可能な限り最大の自由度が得られます。

すべてのアプリケーションプロービング技術には、セクション9で説明されている現在のeff_pmtuより大きいメッセージを送信する機能が必要です。

に最終更新