要約

  • RFC 3322 は 9.6 kbit/s と RTT 140 ms を仮定した SIP/SDP の例から 4,131 ms を算出したが、その近似が粗く、再送遅延を含まないことを明記した。
  • この値は SigComp の設計要件を導く比較材料であり、利用者の実測値、実装適合の証明、導入後の改善保証ではなかった。

変えてよいものと、変えてはいけないもの

メッセージから不要に見えるフィールドを取り除けば、無線区間を通るバイトは減る。しかし RFC 3322 はその近道を選ばなかった。フィールド削除は透明性を失い、エンドツーエンド原則を傷つける。圧縮後に展開された結果は、元のメッセージとビット単位で一致しなければならない。共通層が変更できるのは表現であって、SIP や SDP の意味ではない。

この境界は、当時の問題設定から生まれた。テキスト中心の SIP、SDP、RTSP は、セッション開始時に複数の要求と応答を交換する。無線資源が限られ、誤り訂正やインターリーブが遅延を増やす環境では、各メッセージの大きさが利用者の待ち時間とセル容量の双方に影響し得た。

文書は、単純に利用者当たりの速度を上げる案、RTT を短縮する案、要求応答の順序を変える案、フィールドを削る案、圧縮する案を比較した。速度向上はセル内の他利用者との資源配分を変える。RTT 短縮は無線システム自体の変更を要する。順序変更はアプリケーションプロトコルへ及ぶ。圧縮は、メッセージの同一性を守りながら狭い区間の表現を変えられる点で選ばれた。

4,131 ms の由来

計算式は、メッセージのビット数を毎秒 9,600 ビットで割り、RTT 140 ms の半分を加えるものだった。例示された INVITE、暫定応答、PRACK、200 OK、ACK を合計すると 4,131 ms になる。さらに RSVP、セッション管理、無線ベアラ設定が概算で加わる。

ただし RFC 3322 自身が近似を「rather crude」と呼ぶ。誤りによる再送は無視され、一つのセルラーリンクが仮定され、中間 IP ネットワークも単純化された。メッセージサイズは代表例である。近くに示された GSM 約 3.6 秒、SIP 約 7.9 秒という比較も、SigComp の実測成果ではなく、設計を始める動機だった。

したがって 4.131 秒は、条件付きの問いに対する再計算可能な答えである。ある実利用者の通話設定時間でも、全セルラー網の平均でもない。数字の小数点以下が細かいことと、証拠の範囲が広いことは別である。

“must” は適合証明ではない

2003 年 1 月の RFC 3322 は Informational 文書であり、SigComp プロトコルそのものを規定する標準ではない。任意のメッセージストリーム、UDP と TCP、単方向経路、異なるメモリ・CPU 能力を持つ端末に対応すべきだと要求した。ROHC との共存、後方互換、軽度の順序逆転や損失からの回復も設計課題にした。

圧縮を使うかどうかのネゴシエーションは範囲外で、メッセージを生成する側のプロトコルに委ねられた。SigComp 対応コードが存在することは、あるセッションでネゴシエーションが成立した証拠ではない。圧縮率を上げるために複数メッセージを待つことも、利用者遅延を減らす目的に反する。

RFC 3320 のアーキテクチャ、RFC 3485 の SIP/SDP 辞書、RFC 3486 の SIP 利用、RFC 4077 と RFC 5049 の運用指針は、その後の設計の連鎖を示す。しかし連鎖は普及率や性能測定を自動的には提供しない。実装、導入、観測にはそれぞれ別の証拠が必要である。

RFC 3322 の歴史的価値は、モデルと要件の間にある。モデルは問題を比較可能にし、要件は将来の実装を試験可能にする。どちらも、まだ存在しない実績を宣言する権限ではなかった。

要件文書を残す意味もここにある。後のプロトコルだけを読めば、設計が抽象的な美しさから自然に現れたように見える。運用値だけを読めば、当時避けようとした失敗が消える。RFC 3322 は却下した選択肢と不確実性を同じ記録に置いた。だから後年の実装に対し、ビット同一性、利用者遅延、単方向経路、損失後の回復を個別に問い直せるのである。

Sources