要約

  • RFC 3006は元のSender TSpecを経路上で書き換えず、送信者が圧縮可能性のヒントを添え、対応するリンクを持つ各ルーターだけがローカルな圧縮後TSpecを計算する構造を採った。
  • ヒントを使って少ない資源で受け入れたルーターは、その小さい予算でフローを監視し、実際の圧縮不足を他の予約へ転嫁しない責任を負った。

RFC 3006の例では、同じフローが二つの正しい数字を持つ。送信者のTSpecは48 kbit/s。IP/UDP/RTPの40バイトを4バイトへ縮められるインターフェースでは、120バイトのパケットが84バイトになり、必要な線上帯域は33.6 kbit/sになる。問題は、どちらを全経路の数字にするかではなかった。どの場所で、どの根拠により数字を変えてよいかだった。

送信者が最初から33.6と書けば、圧縮しないホップに対して需要を過小申告する。48のままなら、圧縮可能な低速リンクが本来収容できる予約を拒否するかもしれない。そこで元のSender TSpecはRFC 2210どおり不変にし、圧縮方式と任意の係数を示すヒントを追加した。ヒントは経路全体の命令ではなく、各交通制御器が使える材料である。

この配置はRFC 2205の役割分担にも合う。送信者はデータの形を知る。ルーターはローカルなインターフェースと資源を知る。RSVPは情報を運び、受入制御が判断する。意味を知る主体と実行能力を持つ主体が違うからこそ、共通オブジェクトは可能性だけを渡した。

計算は単一の割合より細かい。r=48 kbit/s、b=120、M=120、m=64のとき、70%係数でrは33.6、bとMは84になる。しかしmは64に0.7を掛けず、36バイトの固定削減を引いて28とする。一般式でも、固定Nバイトを除くヘッダー圧縮ならrとbをf/100倍し、MとmからNを引き、ピークは維持する。

すべての圧縮が固定削減ではない。UDPチェックサム、RTPタイムスタンプの推移、パケット長の分布によって効果は変わる。ルーターは送信者の係数をそのまま信じず、悲観的な値を計算できる。係数ゼロは計算をルーターに委ね、100は節約を期待しない意味だった。

複数送信者では、各TSpecを固有の係数で縮めてから合成する。保証サービスRFC 2212では、受信者のRをバースト量で重み付けした平均係数で調整する。さらにRを下げることでC/Rの遅延が増えないよう、ホップのCを逆方向に補正する。帯域を節約しても、選ばれた遅延目標を密かに劣化させてはならない。

圧縮は完全には決定的でない。33.6を前提に受け入れた出力が35を使えば、余分な1.4は予約外であり、サービスごとの規則で超過として扱われる。送信者が圧縮可能性を誇張すれば、本来拒否すべきフローが入り、他の予約に不足が生じうる。

そこでRFC 3006は、ヒントを使ったルーターを監視上のネットワーク境界とみなした。実際の入口で48以内を確認済みでも、後段の特定リンクで33.6以内になることは証明できない。ローカルな割引を作ったノードだけが、その割引を検証できる。権限と責任を同じ場所に置く設計だった。

最大データグラムMを監視に使うサービスは、未圧縮値を維持した。圧縮できないパケットがありうるからだ。反復的な平均コストと、個々の最大入力は別の証拠であり、一方の改善で他方を消してはいけない。

未知パラメータの扱いも同じ原則に従う。古いルーターはヒントをローカルに無視し、転送時には残し、元の高いTSpecで動くことが望ましい。後段の対応ノードは利用できる。古い実装がPATHを拒否した場合はPathErrを返し、送信者はヒントなしで再試行する。後方互換性とは、知らない最適化を勝手に適用することではなく、既知の保守的契約へ戻ることだった。

周辺RFCとの境界は明確である。RFC 2508はIP/UDP/RTP圧縮自体、RFC 2688はPPP上の変換後コスト、RFC 2689は低速リンク全体の協調を扱う。RFC 3006が所有するのは、申告が資源割引となり、外れれば監視上の結果を生むまでの閉ループである。

後のRFC 3241はROHC over PPP向けにこのヒント体系を参照した。これは拡張可能性の証拠であって、普及率の証拠ではない。確実に読める歴史は、ローカルな実行能力と観測可能な責任を伴うときだけ、圧縮見込みが予約を変えたという点にある。

Lu Hengのレンズでは、最小の共通仕様はヒントを運び、将来判断は各ホップに局在し、採用は強制されない。安定性も予約オブジェクトの存在ではなく、割引を支える圧縮結果の継続で測る。RFC 3006は情報、能力、計算、執行を分けたことで、効率を他者への見えない負債にしなかった。

出典