3. データグラムPLPMTUDを提供するために必要な機能

[RFC4821]で表明されている原則は、任意のPLでの技術の使用に適用されます。TCP PLPMTUDは、標準TCPプロトコルメカニズムを使用して定義されています。TCPとは異なり、データグラムPLはPLPMTUDを実装するために追加のメカニズムと考慮事項を必要とします。

データグラムPLPMTUDの要件

1. PLPMTUの管理

データグラムPLの場合、PLPMTUはDPLPMTUDによって管理されます。PLは、現在のPLPMTUより大きいPLでのサイズを持つデータグラム (プローブパケット以外) を送信してはなりません (MUST NOT)。

2. プローブパケット

PLの下のネットワークインターフェースは、PLPMTUより大きいプローブパケットを送信する方法を提供することが要求されます (REQUIRED)。

• IPv4: プローブパケットは、IPヘッダーにDon't Fragment (DF) ビットを設定し、ネットワーク層エンドポイントフラグメンテーションなしで送信されなければなりません (MUST)。
• IPv6: プローブパケットは常にソースフラグメンテーションなしで送信されます ([RFC8201]セクション5.4で指定されているように)。

3. 受信フィードバック

宛先PLエンドポイントは、プローブパケットが宛先PLエンドポイントによって受信されたときにDPLPMTUD送信者に示すフィードバック方法を提供することが要求されます (REQUIRED)。セクション6は、PLが受信したプローブパケットのこの確認応答を提供する方法の例を提供しています。

4. プローブ損失の回復

損失した場合に再送信が必要なユーザーデータを運ばないプローブパケットを使用することが推奨されます (RECOMMENDED)。ほとんどのデータグラムトランスポートはこれを許可します。

プローブパケットが損失の場合に再送信が必要なユーザーデータを含む場合:

• PL (またはそれ以上の層) は、結果として生じる損失の再送信および/または修復を手配することが要求されます (REQUIRED)。
• PLは、プローブパケットが他の理由 (リンク伝送エラー、輻輳を含む) で失われた場合に堅牢であることが要求されます (REQUIRED)。

5. PMTUパラメータ

• DPLPMTUD送信者は、送信者がローカルリンクで送信できるパケットの最大サイズに関する情報 (例: ローカルリンクMTU) を利用することが推奨されます (RECOMMENDED)。
• PL送信者は、この情報が提供されるときに、受信者が受け入れることができるネットワーク層パケットの最大サイズに関する同様の情報を利用してもよいです (MAY) (これはEMTU_R未満である可能性があることに注意してください)。

これにより、ローカルリンクで転送できないプローブパケットを送信しようとする実装を回避します。値が高すぎると、検索アルゴリズムの効率が低下する可能性があります。一部のアプリケーションには、最大トランスポートプロトコルデータユニット (PDU) サイズもあり、この場合、これより大きいサイズをプローブすることからの利益はありません (トランスポートが複数のアプリケーションのPDUを同じデータグラムに多重化することを許可しない限り)。

6. PTBメッセージの処理

• DPLPMTUD送信者は、ネットワーク層から受信したPTBメッセージをオプションで利用して、ネットワークパスが現在のプローブパケットのサイズをサポートしていないときを識別するのに役立てることができます (MAY)。
• 受信したPTBメッセージは、PLPMTU発見情報を更新するために使用される前に検証されなければなりません (MUST) [RFC8201]。

この検証は、PTBメッセージがDPLPMTUDを実行しているエンドポイントPLによって発信されたパケットに応答して送信されたことを確認します。この検証は、PLPMTU発見方法がPTBメッセージに反応する前に実行される必要があります。

• PTBメッセージはPLPMTUを増加させるために使用してはなりません (MUST NOT) [RFC8201]。
• PTBメッセージは、より大きいPLPMTUをテストするためのプローブをトリガーする可能性があります。

有効なPTB_SIZEは、DPLPMTUDステートマシンで使用される前にPL_PTB_SIZEに変換されます。現在プローブされているものより大きいPL_PTB_SIZEは無視されるべきです (SHOULD) (このPTBメッセージは、さらなる処理なしで破棄されるべきですが、レジリエンスモードを有効にする入力として利用される可能性があります)。

7. プローブと輻輳制御

• PLは、プローブパケットをいつ送信するかを決定するために輻輳コントローラーを使用してもよいです (MAY)。

プローブパケットの送信が輻輳コントローラーによって制限される場合、これにより輻輳中にプローブパケットの送信が遅延または停止される可能性があります。

• プローブパケットの送信が輻輳コントローラーによって制御されない場合、プローブパケット間の間隔は少なくとも1 RTTでなければなりません (MUST)。
• プローブパケットの損失は、輻輳の兆候として扱われるべきではありません (SHOULD NOT)。
• プローブパケットの損失は、輻輳制御反応をトリガーすべきではありません (SHOULD NOT) [RFC4821]。

これは、これが送信レートの不必要な削減をもたらす可能性があるためです。

• PLPMTU (またはMPS) の更新は、バイトで測定された輻輳ウィンドウを増加させてはなりません (MUST NOT) [RFC4821]。

したがって、パケットサイズの増加は、1秒あたりのバイト数でのデータレートの増加を引き起こしません。未処理の固定サイズパケット数の制限の観点から輻輳ウィンドウを維持するPLは、実際のパケットのサイズを補償するためにこの制限を適応させるべきです (SHOULD)。

プローブパケットの送信は、バースト軽減またはペーシングを実行するPLの動作と相互作用する可能性があり、PLはプローブパケットの送信をこれらの方法によって規制する必要がある可能性があります。

8. プローブとフロー制御

PLでのフロー制御は、PLサービスを使用したデータのエンドツーエンドフローに関係します。プローブパケットがリモートアプリケーションにユーザーデータを運ばない設計を使用する場合、フロー制御はDPLPMTUDに適用されるべきではありません (SHOULD NOT)。

9. 共有PLPMTU状態

PLPMTUから計算されたPMTU値は、IP層キャッシュ内の宛先に関連付けられた対応するエントリとともに保存され、他のPLインスタンスによって使用されてもよいです (MAY)。

PLPMTUD [RFC4821]の仕様は、「PLPMTUDが特定のパスのMTUを更新する場合、パス表現を共有するすべてのパケット化層セッション (セクション5.2で説明されているように) は、新しいMTUを使用するように通知されるべきである (SHOULD)」と述べています。このような方法は、基礎となるネットワーク転送動作の広範な多様性に対して堅牢でなければなりません (MUST)。[RFC8201]セクション5.2は、PMTU情報のキャッシングおよびIPv6フローラベルとの関係に関するガイダンスを提供しています。

設計原則

上記の要件に加えて、DPLPMTUDメソッドの設計のために以下の原則が述べられています:

1. データセグメンテーション

• PLは、MPSより大きいデータブロックを複数のデータグラムにセグメント化するように設計されてもよいです (MAY)。

ただし、すべてのデータグラムPLがデータブロックのセグメンテーションをサポートするわけではありません。

• 方法が現在サポートされているPLPMTUを検索している間、アプリケーションに任意に小さいMPSを送信に使用することを強制することを避けることが推奨されます (RECOMMENDED)。

削減されたMPSは、アプリケーションのパフォーマンスに悪影響を与える可能性があります。

2. MPSプリミティブ

適切なデータブロックサイズを選択する際にアプリケーションを支援するために、PLは、PLを使用する上位層にPLPMTUから派生したMPSを返すプリミティブを提供することが推奨されます (RECOMMENDED)。MPSの値は、パスの変更またはプローブパケットの損失に続いて変更される可能性があります。

3. パス検証

方法は、パス特性が最後に確認されて以降に発生した可能性のあるパス変更および受信される可能性のある不整合なパス情報の可能性に対して堅牢であることが推奨されます (RECOMMENDED)。

4. データグラムの並べ替え

方法は、フローが並べ替えに遭遇する可能性またはトラフィック (プローブパケットを含む) が複数のネットワークパスに分割される可能性に対して堅牢であることが要求されます (REQUIRED)。

5. データグラムの遅延と重複

フィードバックメカニズムは、パケットがネットワークパスに沿って大幅に遅延または重複される可能性に対して堅牢であることが要求されます (REQUIRED)。

6. プローブするタイミング

方法は、最後にパスを測定してからパスが変更されたかどうかを判断することが推奨されます (RECOMMENDED)。これは、パスを再度プローブするタイミングを決定するのに役立ちます。

実装上の考慮事項

DPLPMTUDを実装する際は、以下を考慮してください:

1. 効率: ネットワークオーバーヘッドを引き起こす過度のプローブを回避します
2. 堅牢性: さまざまなネットワーク状態と障害シナリオを処理します
3. 相互運用性: 既存のプロトコルと実装との互換性
4. パフォーマンス: アプリケーションパフォーマンスへの影響を最小限に抑えます

これらの要件と原則により、DPLPMTUDがさまざまなネットワーク条件下で確実に動作できることが保証されます。