味噌汁を飲みます

そんなに深く考えて書いていない twitter: siberiy4

PLPMTUD delivers better path MTU discovery for SCTP in Linux(邦訳)

前書き

PLPMTUD delivers better path MTU discovery for SCTP in Linux | Red Hat Developer

RedHat Developerの上記記事を勝手に訳しました。
自分が読むため用のやつです。途中で力尽きました。
問題があれば消します。（ありそう）
基本はFirefoxの Google翻訳拡張、Mouse Dictionary拡張での翻訳ですが意訳しようとするので間違っているところがあると思います。

PLPMTUD はLinuxのSCTPでよりよい Path MTU Discoveryを 提供する。

Path MTU Discoveryとはなんなのか？

maximum transmission unit (MTU)は、 あるネットワークコネクションにおいて転送可能な単一パケットの最大パケットサイズのことである。 // MTUではなく Path MTU の説明であると思われる

それぞれのネットワークノードは、Path MTU Discovery(PMTUD) と呼ばれる規格をもとに送信するパケットのMTUを定義します。
PMTUD の目的は、受信者に到達できる最も効率的なパケットサイズを選択することです。
この記事では、Linux のSCTP の実装においてどのように機能するかを学習します。

Linux SCTP は、RFC 8899 で説明されている Datagram Packetization Layer Path MTU Discovery (DPLPMTUDもしくはただ単に PLPMTUD と表現される) とよばれるアルゴリズムを使用します。
以前の PMTUD とは異なり、この方法は ICMPの Packet Too Big(PTB)メッセージの受信と検証に依存しません。 //つまりICMPブラックホール耐性がある。さらに、Probeに実際のパケットを使用するため実際の経路のPMTUを計測できる
したがって、この新しい実装は従来のPMTUD よりも堅牢です。

SCTP 用の PLPMTUD は、数か月前に Linux カーネルに実装され、Red Hat Enterprise Linuxのバージョン8.6および9.0でサポートされる予定です。

PLPMTUD の背後にある一般的な戦略は、カーネルのパケット化レイヤー (PL) で実行されます。
さまざまなパケット サイズを使用してプローブ パケットを送信し、ネットワーク パスを介して送信できるフラグメント化されていないデータグラムの最大サイズを決定します。
(PL によって決定された)プローブ パケットが正常に配信された場合、 PLPMTUは成功したプローブのサイズに引き上げられます。
ブラック ホールが検出された場合(つまり、一定のサイズのパケットがの応答が繰り返し受信されない場合)、PLPMTU を減らします。

調査と確認

RFC 8899 では、Probeパケットの内容と受信者から返される確認応答(ACK)が定義されています。
各プローブ パケットは、SCTP 共通ヘッダーとそれに続くHEARTBEATチャンクとPADチャンクで構成されます。
HEARTBEATチャンクにより、受信者はプローブが成功したことを確認するためにHEARTBEAT ACKパケットを送り返します。PADチャンクは、プローブ パケットの長さを指定します。

HEARTBEATチャンクは、PROBED_SIZE フィールドのプローブ パケットのサイズを含む Heartbeat Information パラメータも運びます。
受信者は HEARTBEAT ACK パケットでこの値を返すため、送信者は元のプローブのサイズを特定でき、したがって、以降の通信トラフィックのパケット サイズとして割り当てても安全です。
成功した交換の PROBED_SIZE フィールドが PLPMTU よりも大きい場合、送信者はより大きなサイズの使用を開始できます。
//Heartbeat Information パラメータのPROBED_SIZE フィールドにprobeパケットのサイズを含んでいて、受信者はprobeが届いたことを示すHEARTBEAT ACK パケットにPROBED_SIZEを含める必要がある。このHEARTBEAT ACK のPROBED_SIZEが現在の送信上限として保持しているPLPMTUより大きければ、PLPMTUをPROBED_SIZEに変更する。

Linux での実装では、次のサブセクションで説明するタイマーと変数を使用します。

タイマー

トランスポートごと//たぶん宛先ごとに 1 つのタイマーがあります。このタイマーは、Path MTU ディスカバリーが Search Complete 状態の場合は RFC で定義されている PMTU_RAISE_TIMER として使用され、それ以外の状態では PROBE_TIMER として使用されます。
// Search CompleteはPath MTUを探索しきった状態で、経路変更などによって現状ののPLPMTUより大きい値のPath MTUになっていないかPLPMTUより大きいProbeパケットを投げる。

PLPMTUD が有効になり、Path MTU ディスカバリーがベース状態になると、タイマーが開始されます。
タイマーは PROBE_INTERVAL ごとにタイムアウトするため、ノードは応答がなかったために失われたであろうプローブ パケットを再送信します。

Search Complete 状態になると、タイマーは 30 PROBE_INTERVAL 周期ごとにタイムアウトします。その後、ノードはSearch 状態に戻り、必要に応じてタイマーを使用して再送信をトリガーします。

変数

次の変数は、Linux パス MTU ディスカバリーで値と状態を観察します。 - PLPMTU : 確認できた 最新のPROBED_SIZE を保持します。 PLPMTU とpath MTU - sizeof(IP/IPv6 ヘッダー)は等しい。Path MTU ディスカバリーが Search Complete 状態になると、送信に使用されるPath MTU は PLPMTU + sizeof (IP/IPv6 ヘッダー) の値に更新されます。 - PROBE_COUNT: 送信したが連続して失敗したprobeパケットの数のカウント。probe パケットが確認されると、値はゼロに設定されます。 - PROBE_INTERVAL: PLPMTUD probe timerのスケジュールに使用される時間間隔 (ミリ秒単位)。この期間が経過してもノードがプローブ パケットに対する確認応答を受信できなかった場合、タイマーは期限切れになります。この変数は、プローブ検索が行われるときの現在のPath MTU のprobe間の時間間隔でもあります。 - PROBED_SIZE: PL で決定された現在のprobe パケットのサイズ。この値は PLPMTU の暫定的な値であり、承認による確認を待っています。 //つまり実パケットサイズではなく、probeパケットのサイズ
- PTB/PTB_SIZE: 前述のように、PTB は Packet Too Big の略です。これは、Fragmentation Neededと呼ばれることもあります。 PTB_SIZE はPath MTU に関連していますが、IP ヘッダーの長さが値から差し引かれています。

定数

  • BASE_PLPMTU: ほとんどのパスで機​​能すると予想されて設定されたサイズ。1200 に設定されている。 PLPMTUD は、この値を PROBED_SIZE としてプローブを開始します。実際の PLPMTU がより小さいことが判明した場合、カーネルはエラー状態に入り、IP フラグメンテーションを許可します。
  • MAX_PROBES: PROBE_COUNT カウンターの最大値。任意のサイズのprobeの連続試行がこの値を超えると、状態が変化し、異なるリズムでprobeを開始する可能性があります。この定数は 3 に設定されています。
  • BIG_STEP,MIN_STEP: プローブが成功したときに PROBED_SIZE に追加される増分。 BIG_STEP は、検索状態の開始時に使用されます。プローブが失敗した場合は、代わりに MIN_STEP が使用されます。 BIG_STEP は 32 に、MIN_STEP は 4 に設定されています。

Path MTU 検出のオプションを設定するコマンド

システム管理者または開発者は、このセクションのメカニズムを使用してランタイム パラメータを変更できます。 - sysctl sysctl コマンドは、新しいソケットの PROBE_INTERVAL 値のデフォルト値を提供します。

 sysctl -w net.sctp.plpmtud_probe_interval=1

このパラメーターは、ネットワーク名前空間 (netns) に対して設定されます。新しいアソシエーションはソケットから値を取得し、新しいトランスポートはそのアソシエーションから値を取得します。このパラメーターへの変更は、その後に作成されるソケットのみに影響します。

  • setsocketopt PROBE_INTERVAL をきめ細かく設定するために、このシステム コールはソケット、アソシエーション、さらにはトランスポートの値を変更できます。
 setsocketopt(SCTP_PLPMTUD_PROBE_INTERVAL, interval)

Path MTU Discoveryのステートマシンとステップ

図 1 は、パス MTU ディスカバリーの段階と、それらの間でノードがどのように移動するかを示しています。

図 1: Path MTU Discoveryの段階(引用: PLPMTUD delivers better path MTU discovery for SCTP in Linux )

Base → Search → Search Complete

通常のProbeは Base 状態から開始し、BASE_PLPMTU (1200) のPath MTU でProbeします。
パケットが確認応答されると、Path MTU DiscoveryはSerch状態に入ります。次のprobeは、PROBED_SIZE を BIG_STEP (32) ずつ増加することによって開始されます。

この probe-ack-increment-probe シーケンスは、probe パケットの確認応答が失敗するまで続きます。その場合、ノードは、PROBE_INTERVAL ミリ秒待機した後、同じ PROBED_SIZE でさらに 追加で MAX_PROBES-1回 (デフォルトでは 2 回) プローブを再送信します。

これらのprobeが成功しない場合、ノードは PLPMTU でprobeを開始し、毎回 MIN_STEP (4) ずつインクリメントします。これは、以前と同じ方法で 1 つのprobeが失敗するまで続きます。
ノードは、適切な PLPMTU が見つかったと想定します。ノードはトランスポート時にパス MTU を更新し、Search Complete 状態に入ります。

Search Complete → Search → Search Complete

Search Complete 状態では、ノードは、データの再送信に気付かない限り、PROBE_INTERVAL ミリ秒の 30 間隔の間待機します。

データの再送信があるか、30 の PROBE_INTERVAL 期間が満了すると、ノードは検索状態に入ります。 PROBED_SIZE+MIN_STEP の大きさでprobeでprobeが開始されます。
このprobeが確認されると、次のprobeでサイズが BIG_STEP ずつ増加します。
新しい適切な PLPMTU が見つかると、ノードはトランスポート パス MTU をその値で更新し、Search Complete 状態に再び入ります。

Search/Search Complete → Base

検索中に、PROBED_SIZE が PLPMTU に設定された状態でプローブが失敗すると、「ブラック ホールが検出されました」というエラーが発生し、ノードがBase状態に戻ります。

BASE_PLPMTU を使用してもprobeが失敗した場合、ノードはエラー状態になり、IP フラグメンテーションが許可されます。

パケットが大きすぎるか、断片化が必要です

PTB パケット処理中に、PTB_SIZE が PLPMTU と PROBED_SIZE の間にある場合、次のプローブは PROBED_SIZE が PTB_SIZE に設定された状態で開始されます。これにより、適切な PLPMTU を見つける際のプローブの回数を節約できます。

Path MTU Discoveryのシナリオ例

このセクションには、Linux SCTP のさまざまなシナリオで PLPTUD プローブ中に PROBED_SIZE がどのように変化するかを示す例が含まれています。例は、図 2 のトポロジに基づいています。トポロジには、2 つのクライアントと 2 つのインターフェイスを持つルーターがあります。 - link1_1 のホスト (クライアント) は、link1_2 インターフェイスでルーターとパケットを交換します。 - link2_2 のホスト (サーバー) は、link2_1 インターフェイスでルーターとパケットを交換します。

図 2: この例のネットワーク トポロジ(引用: PLPMTUD delivers better path MTU discovery for SCTP in Linux )

まず、クライアントからサーバーへの SCTP 接続を開始します。

sctp_darn -H 192.168.2.1 -P 8888 -l  # on Server
sctp_darn -H 192.168.1.1 -P 8888 -h 192.168.2.1 -p 8888 -s  # on Client

以下の各シナリオでは、Path MTU Discoveryの変更をトリガーするシステム管理コマンドと、カーネルがPath MTU を設定するための手順を示します。

基本シーケンス

Path MTU Discoveryの多くのシーケンスは、このセクションのものに戻ります。シーケンスは、次のコマンドでトリガーできます。

  iptables -A INPUT -p icmp -j DROP  # on Client, disable the classical PMTUD
  ip link set link2_1 mtu 1400  # on Router

Path MTU Discovery のステップ(Base → Search → Complete):

  1. Probed size: 1200 (BASE_PLPMTUで開始)
  2. Probed size: 1200 (BIG_STEP での増加)
  3. Probed size: 1232 → 1264 → ... → 1356
  4. Probed size: 1388 (IPヘッダを付けると1400を超えるので3回のパケロス)
  5. Probed size: 1356 (MIN_STEPでの増加)→ 1360 → 1364 → ... → 1380
  6. Probed size: 1384 (3回のprobeパケロス,1380に戻る )
  7. Probed size: 1380 ( 確認。Complete状態になる、Path MTUにセット）
  8. Probed size: 1380 (raise-timerを超す,Serch状態になる、MIN_STEPでの増加)
  9. Probed size: 1384(3回のprobeパケロス、,1380に戻る)
  10. Probed size: 1380 ( 確認。Complete状態になる、Path MTUにセット） ...

そろそろ飽きたので終わり。