Summary

  • STAMP CoS ECN草案の第02版は、返信パケットに望むECN値を示すEC1と、反射側がそれを設定したかを知らせるRPEを加える。既存のEC2は往路の到着時のECN値を報告する。
  • 要求値を設定できれば反射側はRPE=0b11、設定できずゼロに戻せば0b10を返す。RFC 8972だけを実装する旧端点は新しいビットを予約領域として扱い、0b00を返す。
  • 一つの往復時間内に複数のECT付き試験を送る側は、CEという混雑標識を監視し、往路の送信または自分が発生させる返信負荷を下げられなければならない。

RFC 8762のSTAMPでは、Session-Senderが試験パケットを出し、Session-Reflectorが返す。少ない手順で経路を観察できる。その手軽さゆえに、試験数を増やしても運用者は測定を「背景の作業」と見なしがちだ。実際には一つ一つが送信キューを通り、返信も別のキューを通る。測定装置は結果の受取人であると同時に、経路に仕事を追加する発注者である。

RFC 8972のサービスクラス拡張は、反射側が受け取った試験パケットのECN値をEC2に写せるようにした。往路が見える。一方、復路の返答パケットを狙ったECN値で送り出す指示と、その指示を実行できたという返事はなかった。帰ってきたパケットにCEがないだけでは、ECN対応の返答が復路を通ったかさえ分からない。

2026年11月2日の改訂草案は従来の予約ビットを使う。送信側はEC1で復路パケットの値を求める。反射側は受信時の値をEC2に記録し、要求どおり復路ヘッダーを設定できたらRPE=0b11とする。ローカル方針や機器の制限で設定できなければ、復路ヘッダーを0b00にしてRPE=0b10とする。送信側は実際に戻ってきたIPヘッダーとも照らす。到着時の状態、折り返し時の選択、帰着時の状態を混同しないための三枚の伝票だ。

旧機器との組み合わせにも意味がある。RFC 8972だけを知る反射側はEC1とRPEを予約ビットとして無視し、RPE=0b00で返す。送信側は復路測定機能がないことを知る。0b10なら新しい機能は分かっていても要求した値を設定できなかったと分かる。どちらの場合も、印が付かなかった結果を「復路に混雑なし」と報告する根拠はない。

草案の強い部分は、その後の送信動作だ。一つのRTTのうちにECT(0)またはECT(1)付きの試験を複数出すなら、送信側は返ってきたEC2でCEを監視し、送信レートを下げられなければならない。EC1でECT付きの返信を求める場合も、返答のIPヘッダーを監視し、誘発した返信負荷を減らせる必要がある。一つの試験から複数の返信を求める制御機能を使うなら、次の要求の条件を変更する能力も要る。

具体的な減速方法は実装側に委ね、RFC 3168とRFC 9330の混雑応答条件につなぐ。過負荷時の標識挙動を調べるため一定レートを維持する実験は、対象網の運用者が合意した管理環境で、速度と時間と周辺トラフィックへの影響を限定する場合に限られる。通常の監視計画には、黙って走り続ける理由がない。

数字の前に測定条件を確かめる

往路のECN値とEC2、要求したEC1とRPE、帰着したIPヘッダーを比べれば、標識の変化を検出できる。端点二つの情報だけで変更した中間装置は特定できない。CEのない一通の返信はその一通の記録でしかない。導入済みシステムを評価するなら、両方向の時刻付きパケット、三つの値、試験頻度、返信数、CEを見た後の実際の減速をそろえたい。

文書はまだIETF作業部会の草案である。それでも問いは現場向けに明快だ。測定装置が混雑を見つけたとき、その装置自身は網を少しでも空けたのか。観察の質は、観察者の行動まで含めて判断される。

草案第02版 · RFC 8972 · RFC 8762