Summary
- RFC 9599 は、下位レイヤーのフレームやトンネル外側ヘッダーが除去されても、明示的な輻輳信号を IP へ引き継ぐ方法を整理している。
- 出口で観測した
CEは、その地点のヘッダー状態を示す。どのキューが付けたか、受信側が報告したか、送信側が負荷を下げたかまでは単独で示さない。
トンネル出口のパケットに CE が付いている。監視画面は輻輳を表示する。ここまでは観測である。「このトンネルのこのキューが原因だ」と言い切った瞬間に、観測は帰属へ変わる。
マークはトンネルへ入る前から内側ヘッダーにあったかもしれない。下位レイヤーのキューが外側へ書いた可能性もある。デカプセレータが内外の値を比較し、より強い方を残したのかもしれない。再フレーミングによって、イベントが少し後の IP パケットへ移された可能性もある。DSCP と結び付いた意味が途中で失われたなら、ビットだけが到着して文脈が消える。
2024 年 8 月発行の RFC 9599 は BCP 89 の一部であり、RFC 3819 を更新した。目的は帰属を自動化することではない。IP を包むプロトコルから IP へ輻輳通知を正しく渡し、信号が外側ヘッダーと一緒に捨てられないようにすることだ。
フレームがドロップされれば、中の IP パケットも消える。損失は翻訳なしに上位へ届く。一方、下位ヘッダーへの明示的なマークは、出口でそのヘッダーを外すと消える。パケットだけが先へ進めば、負荷制御に必要な情報は失われる。
したがって、デカプセレータもフィードバックループの構成員である。両端のトランスポートが ECN 対応であるだけでは足りない。信号をロードレギュレータへ戻すために必要な全機能が伝播に参加しなければならない。RFC がいう ECN-PDU は、PDU のビットだけでなくループ全体の能力を表す。能力はヘッダー、ラベル、フロー状態、設定、制御プレーンの関連付けに置かれ得る。
文書は四つのモードを区別する。Feed-forward-and-up は下位レイヤー内で信号を出口へ送り、IP へ上げ、宛先から送信元へ返す。Feed-up-and-forward は下位装置がペイロード中の IP ヘッダーを直接マークする。Feed-backward は下位レイヤー内で入口へ制御を返す。Null は下位ファブリック内部に独自の輻輳点がない構成である。
Feed-backward は閉じたサブネットでは有効でも、IP のエンドツーエンド制御へ直接つながらない。入口だけが送出を絞り、元の送信源が送り続ければ、キューは境界へ移る。入口が制御セルを受け取った事実は、アプリケーション送信源が通知を受けた証拠ではない。
Feed-up-and-forward の限界は可視性にある。暗号化、未知の shim、深いカプセル化によって IP ヘッダーを読めない場合がある。RFC は探索深度を制限し、見つからないときはドロップなど安全な手段へ戻るよう求める。マークがないことは、輻輳がないことではなく、検査できなかったことかもしれない。
Feed-forward-and-up では、入口が下位レイヤーのマーキングを有効にする前に、出口が信号を引き継げると確認する必要がある。MPLS はドメイン全体の設定でこの条件を守れる。内部の一台でもマークするなら、関係する全出口が対応する。これは運用上の不変条件であり、パケット自身の証言ではない。
TRILL はフェイルセーフの例を示す。輻輳フラグを理解しない古い出口は、印を消して転送するのではなくフレームを落とす。ECN を理解しないトランスポートにも、損失という理解可能な信号が残る。
出口は外側の値を内側へ単純コピーしてはならない。両方から出力状態を計算する。内側が Not-ECT で外側に最重度の表示があるなら、パケットを落とす必要がある。Not-ECT へ CE を書いても、読む約束のない信号を作るだけだ。両方が有効な重度を示す場合は強い方を残す。想定不能な組み合わせはログやアラームの対象だが、安全な出力があるなら将来の標準化を妨げる永久的ドロップを固定しない方がよい。
入口で外側の履歴をゼロに戻すべきでもない。入ってきた輻輳水準を外側へ反映すれば、内外の集計差から区間内で増えた輻輳を推定できる。
ただし、それは集計上の推定である。母集団、サンプリング、境界処理がそろって初めて比較できる。再フレーミングでは、マークの時刻を保存する設計と割合を保存する設計が分かれる。パイプラインの都合で少し後の IP パケットに表示されることもある。最終的にマークされたパケットが、キューでイベントを受けた物理単位と同じとは限らない。
ECT(0)、ECT(1)、CE の意味も常に一つではない。通常 ECN、PCN、L4S は異なる文脈を持ち、一部は DSCP に依存する。ドメイン境界が DSCP を変えれば、ビットの伝播に成功しても意味の伝播に失敗し得る。
完全性にも境界がある。中継ノードが正当に変更するフィールドは mutable と定義しなければならない。そうでなければ、正しいマーキングがヘッダー認証を壊す。受信側が報告しても、送信側がレートを下げた証拠にはならない。受領と応答は別の出来事である。
運用上の受入れには、入口の内側 ECN と DSCP、カプセル化規則、トンネル識別子、出口能力、AQM 設定、デカプセル化時の内外状態、転送または意図的ドロップ、受信側報告、送信側受領、レートやキューの実測変化が必要になる。
RFC 9599 は信号を運べるようにする。運べることは、由来が証明されたことではない。コードポイントが語れる範囲を守るほど、後続の判断は強くなる。
Sources
- RFC 9599
- RFC 9599 Datatracker
- RFC 9599 Errata
- RFC 3168:IP の ECN
- RFC 6040:トンネル ECN
- RFC 5129:MPLS の明示的輻輳マーキング
- RFC 7141:バイト/パケット通知
- RFC 7713:ConEx
- RFC 8087:ECN の利点
- RFC 3819:サブネット設計指針
- RFC 8311:ECN 実験
- RFC 7567:AQM 指針
- RFC 4774:代替 ECN 意味論
- RFC 9331:L4S
- RFC 9600:TRILL ECN
- RFC 9601:shim を含む IP トンネルの ECN
- Heng Lu:現実の層と象徴的権力
- Heng Lu:動作するコードの優先
- Heng Lu:主張ではなく現実
会員向け解説
プロフィールの詳細
適切な会員レベルでログインすると、解説全文と出典メモをご覧いただけます。
Strategic Circle 限定
Strategic Circle
すべての読者に公開されています。参加してログインすると プロフィール解説 を閲覧できます。
Strategic Circle に参加Leadership Alliance 会員限定
Leadership Alliance
対象となる IP 資産の所有者・管理者向けです。ログインすると Leadership Alliance の解説を閲覧できます。
Leadership Alliance に参加

