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

7. プロービング方法

このセクションでは、パスMTUを検索するために必要なプローブの送信方法とエラー通知の処理方法を含む、MTUプロービング方法の詳細について説明します。

7.1. パケットサイズ範囲​

このドキュメントでは、3つの状態変数を使用してプロービング方法を説明します:

search_low: 最小の有用なプローブサイズから1を引いたもの。ネットワークはsearch_lowのサイズのパケットを配信できることが期待されます。

search_high: 最大の有用なプローブサイズ。search_highのサイズのパケットは、ネットワークが配信するには大きすぎることが期待されます。

eff_pmtu: このフローの有効PMTU。これは、PLPMTUDがパスに対して許可する最大の非プローブパケットです。

search_low          eff_pmtu         search_high
    |                   |                  |
...------------------------>
非プローブサイズ範囲
    <-------------------------------------->
                プローブサイズ範囲

非プローブを送信する場合、パケット化レイヤーはeff_pmtu以下のサイズのパケットを作成すべきです(SHOULD)。

プローブを送信する場合、パケット化レイヤーはsearch_lowより大きく、search_high以下のプローブサイズを選択しなければなりません(MUST)。

上方向にプロービングする場合、eff_pmtuは常にsearch_lowと等しくなります。初期条件、ICMP PTBメッセージ処理後、または同じパス表現を共有する別のフローでPLPMTUDを実行した後などの他の状態では、eff_pmtuがsearch_lowと異なる場合があります。通常、eff_pmtuはsearch_low以上でsearch_high未満になります。プローブサイズがeff_pmtuより大きいことが一般的に期待されますが、必須ではありません。

パスに関する情報がない初期条件の場合、eff_pmtuがsearch_lowより大きい場合があります。search_lowの初期値は保守的に低く設定すべきです(SHOULD)が、eff_pmtuがより高い、保守的でない値から始まる場合、パフォーマンスが向上する可能性があります。セクション7.2を参照してください。

eff_pmtuがsearch_lowより大きい場合、search_lowより大きい非プローブパケットを送信することが明示的に許可されます。そのようなパケットが確認応答されると、それは事実上「暗黙のプローブ」となり、search_lowは確認応答されたパケットのサイズまで引き上げるべきです(SHOULD)。ただし、「暗黙のプローブ」が失われた場合、真のプローブのようにプローブ失敗として扱ってはなりません(MUST NOT)。eff_pmtuが大きすぎる場合、この状態はICMP PTBメッセージまたはブラックホール検出でのみ検出されます(セクション7.7参照)。

7.2. 初期値の選択​

search_highの初期値は、フローでサポートされる可能性のある最大のパケットであるべきです(SHOULD)。これは、ローカルインターフェースMTU、TCP MSSオプションなどの明示的なプロトコルメカニズム、またはプロトコル長フィールドのサイズなどの本質的な制限によって制限される場合があります。さらに、search_highの初期値は、特定の最大サイズを超えるプロービングを防ぐために設定オプションによって制限される場合があります(MAY)。Search_highは、古典的なパスMTU検出アルゴリズムによって計算される初期パスMTUと同じである可能性が高いです。

search_lowは、非常に広範囲の環境で機能する可能性が高いMTUサイズに初期設定することが推奨されます(RECOMMENDED)。今日の技術を考えると、1024バイトの値はおそらく十分安全です。search_lowの初期値は設定可能であるべきです(SHOULD)。

適切に機能するパスMTU検出は、インターネットの堅牢で効率的な運用にとって重要です。(このドキュメントで説明されているような)大きな変更は、プロトコル動作に予期しない変更を引き起こす場合、非常に破壊的になる可能性があります。eff_pmtuの初期値の選択は、古典的な方法が十分な場合に、PLPMTUD実装の動作が古典的PMTUDにどの程度似ているかを決定します。

保守的な構成は、eff_pmtuをsearch_highに設定し、ICMP PTBメッセージに依存して必要に応じてeff_pmtuを下げることです。この構成では、古典的PMTUDが完全に機能し、PLPMTUDはセクション7.7で説明されている手順を通じてICMPブラックホールから回復するためにのみ呼び出されます。

古典的PMTUDが失敗する可能性が高いことがわかっている場合(たとえば、セキュリティ上の理由でICMP PTBメッセージが管理上無効になっている場合)、小さい初期eff_pmtuを使用すると、ブラックホール検出に必要な高コストのタイムアウトを回避できます。トレードオフは、必要以上に小さい初期eff_pmtuを使用すると、パフォーマンスが低下する可能性があることです。

初期eff_pmtuは、search_lowからsearch_highまでの範囲内の任意の値にできることに注意してください。1400バイトの初期eff_pmtuは、すべての一般的なネットワーク機器上のほぼすべてのトンネルに対して安全であり、今日のインターネットのパスの大部分にとって最適なMTUに近いため、良い妥協点かもしれません。これは、他の最近のフローの統計を使用することで改善される可能性があります。たとえば、フローの初期eff_pmtuは、すべての最近の成功したプローブのプローブサイズの中央値に設定される場合があります。

PLPMTUDのコストは、プローブの生成と処理のプロトコル固有のオーバーヘッドによって支配されるため、各プロトコルが初期eff_pmtuを選択するための独自のヒューリスティックを持つことが望ましいでしょう。特に、コネクションレスプロトコルや、ICMPブラックホールの明確な通知を受け取れない可能性のある他のプロトコルは、セクション10.3で説明されているように、eff_pmtuの保守的な(小さい)初期値を使用することが重要です。

eff_pmtuおよび他のPLPMTUD状態変数の初期値を上書きするために、プロトコルごとおよびルートごとの設定オプションがあるべきです(SHOULD)。

7.3. プローブサイズの選択​

プローブは、上記の「プローブサイズ範囲」内の任意のサイズを持つことができます。ただし、適切なサイズの選択には多くの要因が影響します。単純な戦略は、各プローブでプローブサイズ範囲を半分にする二分探索を行うことかもしれません。ただし、TCPなどの一部のプロトコルでは、失敗したプローブのデータを再送信する必要があるため、失敗したプローブは成功したプローブよりもコストがかかります。このようなプロトコルの場合、プローブサイズをより小さな増分で引き上げる戦略の方がオーバーヘッドが低い可能性があります。パケット化レイヤーおよびその上の多くのプロトコルでは、MTUサイズを増やすことの利点がステップ関数に従う場合があり、特定の領域内でまったくプロービングすることが有利ではない場合があります。

最適化として、標準イーサネットの1500バイト、またはトンネルプロトコルのヘッダーサイズを差し引いた1500バイトなど、特定の一般的または予想されるMTUサイズでプロービングすることが適切な場合があります。

一部のプロトコルは、プローブサイズを選択するために他のメカニズムを使用する場合があります。たとえば、特定の自然なデータブロックサイズを持つプロトコルは、合計サイズがsearch_high未満になり、可能であればsearch_lowより大きくなるまで、多数のブロックからメッセージを組み立てるだけかもしれません。

各パケット化レイヤーは、プロービングが収束したとき、つまりプローブサイズ範囲が十分に小さくなり、さらなるプロービングがそのコストに見合わなくなったときを決定しなければなりません(MUST)。プロービングが収束したら、タイマーを設定すべきです(SHOULD)。タイマーが期限切れになると、search_highを初期値(上記)にリセットして、プロービングを再開できるようにする必要があります。したがって、パスが変更されてパスMTUが増加した場合、フローは最終的にそれを利用します。このタイマーの値は5分未満であってはならず(MUST NOT)、RFC 1981に従って10分にすることが推奨されます。

7.4. プロービングの前提条件​

プローブを送信する前に、フローは少なくとも次の条件を満たさなければなりません(MUST):

  • 未処理のプローブまたは損失がない。
  • 最後のプローブが失敗したか決定的でなかった場合、プローブタイムアウトが期限切れになっている(セクション7.6.2参照)。
  • 使用可能なウィンドウがプローブサイズより大きい。
  • プロービングにインバンドデータを使用するプロトコルの場合、プローブを送信するのに十分なデータが利用可能である。

さらに、ほとんどのプロトコルのタイムリーな損失検出アルゴリズムには、プローブを送信する前に満たすべき(SHOULD)前提条件があります。たとえば、TCP Fast Retransmitは、プローブに続く十分なセグメントがない限り堅牢ではありません。つまり、送信者はプローブと少なくともTcprexmtthresh [RFC2760]の追加セグメントを送信するのに十分なデータをキューに入れ、十分な受信ウィンドウを持つべきです(SHOULD)。この制限は、接続の終わりに近すぎる場合やウィンドウが小さすぎる場合など、一部のプロトコル状態でプロービングを阻害する可能性があります。

プロトコルは、プロービングの前提条件を満たすのに十分なデータを蓄積するために、非プローブの送信を遅らせることができます(MAY)。遅延送信アルゴリズムは、データが遅延される時間を適切に制限するために、自己スケーリング技術を使用すべきです(SHOULD)。たとえば、返されるACKを使用して、ウィンドウがプローブに必要なデータ量以上に減少しないようにすることができます。

7.5. プローブの実施​

適切な範囲のプローブサイズが選択され、上記の前提条件が満たされると、パケット化レイヤーはプローブを実施できます(MAY)。そのために、最も外側のIPヘッダーを含むサイズがプローブサイズと等しいプローブパケットを作成します。プローブを送信した後、次のいずれかの結果を持つ応答を待ちます:

成功: プローブがリモートホストによって受信されたことが確認応答される。

失敗: プロトコルメカニズムがプローブが失われたことを示すが、先行または後続ウィンドウ内のパケットは失われていない。

タイムアウト失敗: プロトコルメカニズムがプローブが失われたことを示し、先行ウィンドウ内のパケットは失われていないが、後続ウィンドウ内のパケットが失われたかどうかを判断できない。たとえば、損失がタイムアウトによって検出され、go-back-n再送信が使用される。

決定的でない: プローブが先行または後続ウィンドウ内の他のパケットに加えて失われた。

7.6. プローブ結果への応答​

プローブが完了したら、結果はプローブの結果タイプによって分類され、次のように処理されるべきです(SHOULD)。

7.6.1. プローブ成功​

プローブが配信されると、パスMTUが少なくともプローブサイズと同じ大きさであることを示します。search_lowをプローブサイズに設定します。プローブサイズがeff_pmtuより大きい場合、eff_pmtuをプローブサイズまで引き上げます。プローブサイズは、フローが対話型セッションで利用可能なデータなどの他の制限の対象であるため、パスの完全なMTUを使用していない場合、eff_pmtuより小さい場合があります。

フローのパケットが複数のパスを経由してルーティングされている場合、または非決定的MTUを持つパスを経由している場合、単一のプローブパケットの配信は、そのサイズのすべてのパケットが配信されることを示すものではありません。このような場合に堅牢であるために、パケット化レイヤーはセクション7.8で説明されているMTU検証を実施すべきです(SHOULD)。

7.6.2. プローブ失敗​

プローブのみが失われた場合、それはパスMTUがプローブサイズより小さいことを示すものとして扱われます。この場合に限り、損失は輻輳信号として解釈すべきではありません(SHOULD NOT)。

他の通知がない場合、search_highをプローブサイズから1を引いた値に設定します。eff_pmtuは、フローが対話型セッションで利用可能なデータなどの他の制限の対象であるため、パスの完全なMTUを使用していない場合、プローブサイズより大きい場合があります。eff_pmtuがプローブサイズより大きい場合、eff_pmtuはsearch_high以下に縮小しなければならず(MUST)、完全停止タイムアウト後と同様に、eff_pmtuが無効であると判断されたため、search_lowに縮小すべきです(SHOULD)(セクション7.7参照)。

プローブパケットに一致するICMP PTBメッセージが受信された場合、search_highおよびeff_pmtuは、メッセージに示されているMTU値から設定できます(MAY)。ICMPメッセージは、プロトコル損失通知の前または後に受信される場合があることに注意してください。

プローブ失敗イベントは、パケット化レイヤーが損失を輻輳信号として無視すべき(SHOULD)唯一の状況です。輻輳制御の抑制が予期しない結果をもたらす可能性がわずかにあるため(孤立した損失に対してさえ)、プローブ失敗イベントは標準輻輳制御下での損失の通常期間よりも頻度が低いことが要求されます(REQUIRED)。具体的には、プローブ失敗イベントと輻輳制御の抑制の後、PLPMTUDは、輻輳制御イベント間の予想間隔よりも大きい間隔まで再度プロービングしてはなりません(MUST NOT)。詳細についてはセクション4を参照してください。次の輻輳イベントまでの間隔の最も単純な推定は、パケット内の現在の輻輳ウィンドウと同じラウンドトリップ数です。

7.6.3. プローブタイムアウト失敗​

損失がタイムアウトで検出され、go-back-n再送信で修復された場合、輻輳ウィンドウの縮小が必要になります。この場合の失敗したプローブの比較的高いコストは、次のプローブまでのより長い時間間隔を必要とする場合があります。非タイムアウト失敗の場合(セクション7.6.2)の5倍の時間間隔が推奨されます(RECOMMENDED)。

7.6.4. プローブ決定的でない​

プローブの損失の近くに他の損失があることは、プローブがMTU制限ではなく輻輳のために失われたことを示している可能性があります。この場合、状態変数eff_pmtu、search_low、およびsearch_highは更新すべきではなく(SHOULD NOT)、プロービングの前提条件が満たされるとすぐに(つまり、パケット化レイヤーに未回復の損失がなくなると)、同じサイズのプローブを再度試行すべきです(SHOULD)。この時点では、フローの輻輳ウィンドウが最低点にあり、輻輳損失の確率を最小限に抑えるため、再プロービングが特に適切です。

7.7. 完全停止タイムアウト​

すべての条件下で、完全停止タイムアウト(他のドキュメントでは「持続タイムアウト」とも呼ばれる)は、ルーター障害やより小さいMTUを持つパスへのルーティング変更など、ネットワーク内の大幅に破壊的なイベントの通知として扱うべきです(SHOULD)。TCPの場合、これは[RFC1122]によって説明されているR1タイムアウトしきい値が期限切れになったときに発生します。

完全停止タイムアウトがあり、理由を示すICMPメッセージ(PTB、ネットワーク到達不能など、またはICMPメッセージが何らかの理由で無視された)がなかった場合、推奨される最初の回復アクションは、これを[RFC2923]で定義されている検出されたICMPブラックホールとして扱うことです。

検出されたブラックホールへの応答は、search_lowおよびeff_pmtuの現在の値に依存します。eff_pmtuがsearch_lowより大きい場合、eff_pmtuをsearch_lowに設定します。それ以外の場合は、eff_pmtuとsearch_lowの両方をsearch_lowの初期値に設定します。追加の連続したタイムアウトでは、search_lowおよびeff_pmtuは半分にすべきであり(SHOULD)、IPv4の場合は68バイト、IPv6の場合は1280バイトの下限があります。IP仕様で許可されているよりも小さいMTUを持つリンク上での限定的な動作をサポートするために、さらに低い下限が許可される場合があります(MAY)。

7.8. MTU検証​

フローが同時に複数のパスを通過することは可能ですが、実装はフローの単一のパス表現のみを保持できます。パスに異なるMTUがある場合、フローのパス表現にすべてのパスの最小MTUを格納すると、正しい動作になります。ICMP PTBメッセージが配信される場合、古典的PMTUDはこの状況で正しく機能します。

ICMP配信が失敗し、古典的PMTUDが壊れている場合、接続はPLPMTUDのみに依存します。この場合、PLPMTUDも失敗する可能性があります。これは、フローが単一のMTUを持つパスを通過すると想定しているためです。最小値より大きいがパスMTUの最大値より小さいサイズのプローブは成功する可能性があります。ただし、フローの有効PMTUを引き上げると、損失率が大幅に増加します。フローは依然として進行する可能性がありますが、結果として生じる損失率は受け入れられない可能性があります。たとえば、双方向ラウンドロビンストライピングを使用する場合、フルサイズパケットの50%がドロップされます。

この方法でのストライピングは、他の理由(たとえば、パケットの並べ替えのため)で運用上望ましくないことが多く、通常、各フローを単一のパスにハッシュすることで回避されます。ただし、堅牢性を高めるために、実装は、eff_pmtuを増やすと損失率が急激に増加した場合に、より低いMTUの使用にフォールバックするように、何らかの形式のMTU検証を実装すべきです(SHOULD)。

推奨される戦略は、eff_pmtuの値を引き上げる前に保存することです。その後、一定期間(たとえば、複数の再送信タイムアウト(RTO)間隔にわたって損失率が10%を超える)損失率がしきい値を超えて上昇した場合、新しいMTUは正しくないと見なされます。eff_pmtuの保存された値を復元し(SHOULD)、プローブ失敗と同じ方法でsearch_highを縮小すべきです。PLPMTUD実装はMTU検証を実装すべきです(SHOULD)。

に最終更新