5. データグラムパケット化レイヤーPMTUD
このセクションでは、データグラムPLPMTUD(DPLPMTUD)を指定します。この方法は、IPプロトコルスタックのさまざまなポイントで導入され、アプリケーションが現在のネットワークパスに適した MPSを利用できるようにPLPMTUを発見できます。
DPLPMTUDは、エンドポイントのペア間で一層のみで実行すべきです。したがって、DPLPMTUDが下位層で有効になっている場合、上位層のPLまたはアプリケーションはDPLPMTUDの使用を避けるべきです。PLは、PLによって導入される追加のオーバーヘッドを考慮して、DPLPMTUDによって示されたMPSを調整しなければなりません。
DPLPMTUD実装場所の例
Application Data *
↓
QUIC/RTP * (DPLPMTUDを実装可能)
↓
UDP * (DPLPMTUDを実装可能)
↓
IP Layer
↓
Network Interface
DPLPMTUDの中心的なアイデアは、送信者によるプロービングです。プローブパケットが送信され、送信者から宛先に完全に転送できるユーザーメッセージの最大サイズを見つけます。
以下のセクションでは、実装に必要なコンポーネントを特定し、動作フェーズの概要を提供し、状態マシンと検索アルゴリズムを指定します。
5.1. DPLPMTUDコンポーネント
このセクションでは、DPLPMTUDのタイマー、定数、および変数について説明します。
5.1.1. タイマー
この方法は、最大3つのタイマーを利用します:
PROBE_TIMER
- 構成: プローブパケットへの確認応答を受信する最大時間より大きいタイムアウト
- 最小値: 1秒未満であってはなりません
- 推奨: 15秒より大きくすべきです
- 参照: UDPの使用ガイドライン[BCP145]のセクション3.1.1は、タイマー値の選択に関するガイダンスを提供します
PMTU_RAISE_TIMER
- 機能: 送信者が現在のPLPMTUを使用し続ける期間、その後、検索フェーズに再び入ります
- 期間: PLPMTUD[RFC4821]で推奨されているように、600秒
- 最適化: DPLPMTUDは、最後のプローブパケット以降にアプリケーションデータが送信されていない場合、プローブパケットの送信を抑制してもよいです。ユーザーデータを再び送信するときに最新のPMTUを使用することを好むPLは、各パスのPMTU発見を続けることを選択できます。ただし、これにより追加のパケットが送信されます
CONFIRMATION_TIMER
- 適用性: 確認応答されたPLが使用されている場合は使用してはなりません
- 機能: 他のPLの場合、PL送信者が現在のPLPMTUがまだサポートされていることを確認するまで待つ期間として構成されます
- 関係: PMTU_RAISE_TIMERより小さく、PLPMTUを減らすために使用されます(例えば、ブラックホールに遭遇したとき)
- 頻度: データが流れているときに送信PLが大量のトラフィックをブラックホールしないように、確認は十分に頻繁である必要があります
- 参照: UDPの使用ガイドライン[BCP145]のセクション3.1.1は、タイマー値の選択に関するガイダンスを提供します
- 最適化: DPLPMTUDは、最後のプローブパケット以降にアプリケーションデータが送信されていない場合、プローブパケットの送信を抑制してもよいです
注意: DPLPMTUDはさまざまなタイマーを指定しますが、実装はこれらのタイマー機能を単一のタイマーを使用して実現することを選択できます。
5.1.2. 定数
以下の定数が定義されています:
MAX_PROBES
- 定義: PROBE_COUNTカウンターの最大値
- 意味: あらゆるサイズの連続するプローブ試行の数に対する制限を表します
- 利点: 1より大きいMAX_PROBES値は、孤立したパケット損失に対する堅牢性を提供できます
- デフォルト: 3
MIN_PLPMTU
- 定義: DPLPMTUDが使用を試みる最小のPLPMTUサイズ
- 構成: エンドポイントは、PL以下の層での拡張ヘッダーおよび他のカプセル化のためのスペースを提供するために、MIN_PLPMTUを構成する必要がある場合があります
- パス依存性: この値は、インターフェースとパスに依存する場合があります
- IPv6: このサイズは、[RFC8200]で指定されているように、1280バイトのIPv6パケットになるPLでのサイズ以上です
- IPv4: このサイズは、68バイトのIPv4パケットになるPLでのサイズ以上です
- 注意: IPv4ルーターは、さらなる断片化なしに68バイトのデータグラムを転送できることが要求されています。これは、IPv4ヘッダーと8バイトの最小断片サイズの合計サイズです。さらに、[RFC1122]のセクション3.3.3に記載されているように、受信者は少なくとも576バイトのサイズの断片化されたデータグラムを再構成できることが要求されています
MAX_PLPMTU
- 定義: 最大のPLPMTUサイズ
- 制限: 送信インターフェースで送信できるPLパケットの最大サイズ以下でなければなりません(ローカルインターフェースMTUによって制約されます)
- 考慮事項: これが既知の場合、リモートエンドポイントが受信できるPLパケットの最大サイズ(EMTU_Rによって制約される)よりも小さくすべきです
- 設計上の制限: 使用中のPLの設計または構成によって制限される場合があります
- アプリケーション制限: アプリケーションまたはPLは、特定のサイズより大きいパケットを送信する必要がない場合、より小さいMAX_PLPMTUを選択してもよいです
BASE_PLPMTU
- 定義: ほとんどのパスで機能すると予想される構成サイズ
- 範囲: MIN_PLPMTU以上かつMAX_PLPMTUより小さい
- 推奨: ほとんどのPLの場合、適切なBASE_PLPMTUは1200バイトより大きくなります
- IPv4: IPv4を使用する場合、現在指定されている同等のサイズはありません。1200バイトのデフォルトBASE_PLPMTUが推奨されます
5.1.3. 変数
この方法は、一連の変数を利用します:
PROBED_SIZE
- 定義: PLで決定された現在のプローブパケットのサイズ
- 性質: これは、確認待ちのPLPMTUの暫定値です
PROBE_COUNT
- 定義: 送信された連続する失敗したプローブパケットの数のカウント
- リセット: プローブパケットが確認応答されるたびにゼロに設定されます
- 注意: 検索中にプローブの一部の損失が予想されるため、単一のプローブの損失はPMTU問題の兆候ではありません
パケットサイズ関係図
MAX_PLPMTU ────────┐
│
↓
PROBED_SIZE ───────┤ (プローブ中)
│
↓
PLPMTU ────────────┤ (現在使用)
│
↓
BASE_PLPMTU ───────┤ (ベースライン)
│
↓
MIN_PLPMTU ────────┘ (最小)
上の図は、DPLPMTUDアルゴリズムがPLPMTUサイズを増やすためにパスプロービングを実行する際の、パケットサイズの定数と変数の関係を示しています。PROBED_SIZEのサイズのプローブパケットが送信されました。確認応答されると、PLPMTUがPROBED_SIZEに引き上げられ、DPLPMTUDアルゴリズムがPROBED_SIZEをさらに増やし、実際のPMTUサイズのプローブパケットの送信に向かいます。
5.1.4. DPLPMTUDフェーズの概要
このセクションでは、いくつかの動作フェーズを通じた方法の移動を説明することにより、DPLPMTUD方法の高レベルで有益なビューを提供します。詳細は、状態マシン(セクション5.2)にあります。
DPLPMTUDフェーズフロー図
Initial → Base Phase → Search Phase → Search Complete Phase
↓ ↑
└──────→ Error Phase ←──────────────┘
ベースフェーズ
- 目的: ベースフェーズは、BASE_PLPMTUサイズのパケットを使用して、リモートピアへの接続性を確認します
- 接続確認: 接続指向のPLの場合、接続確認は暗黙的です(PL接続ハンドシェイクで実行できます)。コネクションレスPLは、プローブパケットを送信し、このプローブパケットの確認応答を使用して、リモートピアに到達可能であることを確認します
- PLPMTU確認: 送信者はまた、ネットワークパスがBASE_PLPMTUをサポートすることを確認します。これは、PLメカニズム(例えば、BASE_PLPMTUサイズのハンドシェイクパケットを使用)を使用するか、BASE_PLPMTUサイズのプローブパケットを送信し、そのプローブパケットの受信を確認することによって達成できます
- プローブタイミング: BASE_PLPMTUサイズのプローブパケットは、ベースフェーズに入った直後(接続チェックに続いて)に送信できます。BASE_PLPMTUより小さいPLPMTUを持つパスをサポートしたくないPLは、BASE_PLPMTUサイズのプローブを使用して接続チェックを実行することにより、このフェーズを単一のステップに簡略化できます
- 成功: 確認されると、DPLPMTUDは検索フェーズに入ります
- 失敗: ベースフェーズがBASE_PLPMTUの確認に失敗した場合、DPLPMTUDはエラーフェーズに入ります
検索フェーズ
- 目的: 検索フェーズは、検索アルゴリズムを利用してプローブパケットを送信し、PLPMTUを増やそうとします
- 終了: 適切なPLPMTUが見つかると、検索完了フェーズに入ることによってアルゴリズムが終了します
- PTB応答: PLは、PTBメッセージを使用して検索を進めるか終了することができます。セクション4.6を参照してください
検索完了フェーズ
- 状態: 検索完了フェーズは、PLPMTUがネットワークパスでサポートされているときに入ります
- 定期的確認: PLは、CONFIRMATION_TIMERを使用して、現在のPLPMTUサイズのプローブパケットを定期的に繰り返すことができます
- ブラックホール検出: 送信者が到達可能性を確認できない場合(例えば、CONFIRMATION_TIMERが期限切れになった場合)またはPLが到達可能性の欠如を通知する場合、ブラックホールが検出され、DPLPMTUDはベースフェーズに入ります
- 定期的検索: PMTU_RAISE_TIMERは、PLPMTUを引き上げることができるかどうかを発見するために、定期的に検索フェーズを再開するために使用されます
エラーフェーズ
- トリガー: パスのPLPMTU情報が矛盾しているか無効である場合(例えば、BASE_PLPMTUをサポートできない)、エラーフェーズに入ります。これにより、DPLPMTUDが継続できなくなり、PLPMTUが減少します
- 緩和: この状態は、状態イベントエンジンの振動を緩和する方法を実装します。PL経由で上位層に保守的なMPS値を通知します
- 終了: プローブパケットがエラーを検出しなくなると、この状態から抜けます。PL送信者は検索状態に入ります
堅牢性: PLPMTUを適切なサイズに削減するだけの方法は、信頼性の高い動作を保証するのに十分ですが、実際のPMTUが変更された場合や、方法が(何らかの理由で)PLPMTUに対して最適でない選択を行った場合に非常に非効率的になる可能性があります。
完全な実装: DPLPMTUDの完全な実装は、リンクがより大きなMTUで再構成されたときや、エンドツーエンドフローが横断するリンクのセットに変更があったとき(例えば、ルーティングまたはパスフェールオーバー決定の後)など、パス特性の変更に続いてDPLPMTUD送信者がPLPMTUを増やすことができるアルゴリズムを提供します。
5.2. 状態マシン
DPLPMTUDの状態マシンを以下に示します。マルチパスまたはマルチホーミングがサポートされている場合、各パスに状態マシンが必要です。
注意: わかりやすくするために、図はすべての遷移を示していません。
状態マシン図
[DISABLED]
↓ ↑
Connection Established/Lost
↓ ↑
[BASE] ←──────────────┐
↓ │
Probe Success Black Hole Detection
↓ │
[SEARCHING] ─────────────┤
↓ │
Probe Complete/Fail │
↓ │
[SEARCH_COMPLETE] ──────────┘
↑ ↓
Periodic Raise/Black Hole Detection
[ERROR]
(エラー処理)
状態の定義
DISABLED
- 初期状態: プロービングが開始される前の初期状態
- 進入条件: PLが接続性の喪失を示すと、他の任意の状態から入ります
- 退出条件: PLがリモートPLへの接続性を示すと、この状態を離れます
- 遷移: BASE状態に遷移するとき、BASE_PLPMTUサイズのプローブパケットを即座に送信できます
BASE
- 目的: ネットワークパスがBASE_PLPMTUサイズをサポートすることを確認するために使用されます。実際のPMTUが一時的に減少した場合にアプリケーションが動作し続けることを可能にすることを意図しています。また、DPLPMTUDを使用する送信者が、より大きなPLPMTUを検索している間、パケットまたはICMPブラックホールが原因でパケットが配信されていないことを知らないことを避けようとします
- 進入時: PROBED_SIZEはBASE_PLPMTUサイズに設定され、PROBE_COUNTはゼロに設定されます
- プロービング: プローブパケットが送信されるたびに、PROBE_TIMERが開始されます
- 成功終了: プローブパケットが確認応答されると、状態から抜け出し、PL送信者はSEARCHING状態に入ります
- 失敗終了: PROBE_COUNTがMAX_PROBESに達したとき、または検証されたPTBメッセージが受信されたときにも、状態から抜けます。これにより、PL送信者はERROR状態に入ります
SEARCHING
- 主状態: これは主要なプロービング状態です
- 進入条件: BASE_PLPMTUのプローブが完了したときに入ります
- 成功したプローブ: プローブパケットが確認応答されるたびに、PROBE_COUNTがゼロに設定され、PLPMTUがPROBED_SIZEに設定され、PROBED_SIZEが検索アルゴリズムを使用して増加されます(セクション5.3で説明)
- プローブ失敗: PROBE_TIMER期間内に確認応答されずにプローブパケットが送信されると、PROBE_COUNTが増分され、新しいプローブが送信されます
- 退出条件: PROBE_COUNTがMAX_PROBESに達してSEARCH_COMPLETEに入るとき、最後に成功したプローブサイズに対応する検証されたPTBが受信されたとき(PL_PTB_SIZE = PLPMTU)、またはMAX_PLPMTUサイズのプローブが確認応答されたとき(PLPMTU = MAX_PLPMTU)に終了します
- ブラックホール検出: SEARCHING状態にあるときにブラックホールが検出されると、PL送信者はBASE状態に入ります
SEARCH_COMPLETE
- 完了フラグ: 検索が完了したことを示します。これは、PLがPLPMTUを更新するためにプロービングしていない通常のメンテナンス状態です
- 期間: PMTU_RAISE_TIMERが期限切れになるか、ブラックホールが検出されるまで、DPLPMTUDはこの状態にとどまります
- 未確認PL: DPLPMTUDが未確認PLを使用し、SEARCH_COMPLETE状態にあるとき、CONFIRMATION_TIMERは定期的にPROBE_COUNTをリセットし、PLPMTUサイズのプローブパケットをスケジュールします。MAX_PROBES回連続してPLPMTUサイズのプローブパケットが確認応答されない場合、方法はBASE状態に入ります
- 確認済みPL: 確認応答されたPL(例えばSCTP)で使用される場合、DPLPMTUDはこの状態でPLPMTUプローブを生成し続けるべきではありません
ERROR
- 失敗状況: ネットワークパスが少なくともBASE_PLPMTUサイズのPLPMTUをサポートすることが知られていないか、上位層へのMPS信号が過度に振動する可能性のあるネットワークパスに関する矛盾した情報があることを示します
- 振動緩和: この状態は、状態イベントエンジンの振動を緩和する方法を実装します
- 保守的な値: PL経由で上位層に保守的なMPS値を通知します
- 終了: プローブパケットがエラーを検出しなくなると、この状態から抜けます。PL送信者は検索状態に入ります
- エンドポイント断片化: 実装は、DPLPMTUDがPROBE_COUNTプローブ内でMIN_PLPMTUを検証できない場合、エンドポイント断片化を有効にすることを許可します
- 無効化: DPLPMTUDがMIN_PLPMTUを検証できない場合、実装はDISABLED状態に遷移します
- 注意: MIN_PLPMTUはBASE_PLPMTUと同じにすることができ、この状態の動作を簡略化します
5.3. PLPMTUを増やすための検索
このセクションでは、DPLPMTUDがより大きなPLPMTUを検索するために使用するアルゴリズムについて説明します。
5.3.1. より大きなPLPMTUのプロービング
実装は、検索範囲全体で検索アルゴリズムを使用して、ネットワークパスがより大きなPLPMTUをサポートできるかどうかを判断します。
この方法は、最小PLPMTUを確認し、次にプロービングを使用してMAX_PLPMTU以下のPROBED_SIZEを選択することにより、検索範囲を発見します。MAX_PLPMTUは、ローカルMTUとEMTU_R(リモートエンドポイントから学習したとき)の最小値です。MAX_PLPMTUは、送信するデータグラムのサイズに最大値を設定するアプリケーションによって削減してもよいです。
PLPMTU以上のサイズの最初のプローブが送信されるとき、PROBE_COUNTはゼロに初期化されます。リモートピアに正常に送信された各プローブパケットは、PLからの確認応答によって確認されます(セクション4.1を参照)。
プローブパケットが宛先に送信されるたびに、PROBE_TIMERが開始されます。プローブパケットがパス全体に正常に送信されたことをPLが確認応答を受信すると、タイマーはキャンセルされます(セクション4.1)。これにより、PROBED_SIZEがサポートされることが確認され、PROBED_SIZE値がPLPMTUに割り当てられます。検索アルゴリズムは、サイズを増やして後続のプローブを送信し続けることができます。
プローブパケットが確認応答される前にタイマーが期限切れになった場合、プローブはPROBED_SIZEの確認に失敗しました。PROBE_TIMERが期限切れになるたびに、PROBE_COUNTが増分され、PROBE_TIMERが再初期化され、同じサイズまたは他の任意のサイズの新しいプローブ(検索アルゴリズムによって決定される)を送信できます。連続した失敗したプローブの最大数(MAX_PROBES)が構成されます。PROBE_COUNTの値がMAX_PROBESに達すると、プロービングが停止し、PL送信者はSEARCH_COMPLETE状態に入ります。
5.3.2. プローブサイズの選択
検索アルゴリズムは、PLPMTUの最小限の有用な増加を決定します。PL送信者がすべてのサイズをプローブしようとすることは建設的ではありません。これはパスに不必要な負荷をかけることになります。実装は、各検索ステップからのPLPMTUのゲインを最大化するために、プローブパケットサイズのセットを選択すべきです。
実装は、一般的なPMTUサイズのテーブルからステップサイズを選択することにより、検索手順を最適化できます。検索する適切な次のサイズを選択する際、実装者は、アプリケーションが使用しようとする可能性のある一般的なMPSサイズや、ネットワーク内で使用されている一般的なMTUサイズがある可能性があることも考慮すべきです。
5.3.3. 一貫性のないパス情報への耐性
PLPMTUを増やす決定は、ネットワークパスについて学習した情報の不一致の可能性に対して耐性がある必要があります。パスの不一致は、プローブパケットがパケットサイズ以外の理由(つまり、サイズに関連しない損失)で失われたとき、または頻繁なパス変更が原因で発生する可能性があります。頻繁なパス変更は、予期しない「ジッター」から生じる可能性があります。フローの一部のパケットは1つのパスに沿って配信されますが、他のパケットは異なるプロパティを持つ別のパスをたどります。
PL送信者は、確認応答されたPLPMTUプローブのシーケンスから、または受信したPTBメッセージのシーケンスから、不一致を検出できます。PL送信者は、一貫性のないパス情報を検出したときに、代替検索パターンを使用できます。これは、一定期間、より小さい値に提供されるMPSを制限します。これにより、不必要なパケット損失が回避されます。
5.4. 一貫性のないパスへの堅牢性
一部のパスは、BASE_PLPMTUサイズのパケットを維持できない可能性があります。エラー状態は、そのようなパスの堅牢性を提供するために実装できます。これにより、接続の失敗を受けるのではなく、望ましいよりも小さいPLPMTUへのフォールバックが可能になります。これは、PL送信者がBASE_PLPMTUより小さいパケットを使用して通信できるようにするために、エンドポイントIP断片化などの方法を利用できます。
アルゴリズムの要約
DPLPMTUDアルゴリズムの主要な要素:
- 保守的な開始: BASE_PLPMTUから開始します
- 段階的プロービング: プローブサイズを徐々に増やします
- 確認メカニズム: 各サイズが利用可能であることを確認します
- ブラックホール検出: パスの問題に迅速に対応します
- 定期的メンテナンス: PLPMTUを最新の状態に保ちます
- エラー回復: 例外的な状況を処理します
これらのメカニズムが一緒になって、DPLPMTUDがさまざまなネットワーク条件下で確実かつ効率的に動作できることを保証します。