要約

  • RFC 3320 は、送信側が解凍プログラムを持ち込む場合も含め、シグナリングメッセージごとに独立した制限付き仮想機械を実行する設計を定めた。
  • 解凍に成功しただけでは永続状態を作れない。アプリケーションが結果を認証し、有効な compartment 識別子を返して初めて、新しい状態の保存や圧縮側へのフィードバックが許される。

圧縮されたのはデータだけではない

2003 年 1 月の RFC 3320 は、SIP や RTSP などのアプリケーション向けに Signaling Compression、すなわち SigComp を定義した。通信する両端に同じ圧縮アルゴリズムがあらかじめ実装されている、という前提は置かない。送信側は方式を選び、必要ならバイトコードをメッセージに含め、受信側の Universal Decompressor Virtual Machine（UDVM）に実行させる。受信機は柔軟な解凍を受け入れながら、遠隔から持ち込まれた計算がホストを自由に操作しないようにする必要があった。

そのため、歴史的な問いは「何バイト節約できるか」だけではない。受信メッセージがどの計算を起動できるか、そしてどんな情報を受信側に記憶させられるかも問われる。RFC はプロトコル上の境界を示すが、SigComp の普及率や実運用での帯域削減量を証明するものではない。送信者には制約付きの計算を提案する余地を与えつつ、資源の上限と現在のメッセージを越えて何を残すかという権限は受信側に置いた。

各メッセージを新しい実行単位にする

受信した SigComp メッセージごとに、別個の UDVM インスタンスが起動する。解凍用メモリにはメッセージ単位の上限があり、各エンドポイントは少なくとも 2,048 バイトを提供しなければならない。命令数もメッセージ長と cycles_per_bit によって制限される。n バイトのメッセージなら上限は (8*n + 1000) * cycles_per_bit で、パラメーターの最小値は 16 だ。これは一回の実行に対する上限であり、ホスト全体の資源消費を表す完全な式でも、あらゆるサービス拒否への免疫保証でもない。

新しいインスタンスは障害の局所化に役立つ。あるメッセージが不正だったり命令予算を使い切ったりしても、後続の正常なメッセージが同じ仮想機械に閉じ込められるとは限らない。状態が際限なく積み上がる単一のストリームデコーダーを前提にしなくてよい。プロトコルは実行をやり直す境界を明示しながら、選択された状態だけはメッセージ間で共有できるようにした。この二つは別の制御面である。

解凍と記憶は別々の許可

SigComp は、解凍時の一時メモリと、compartment に割り当てる状態メモリを区別する。compartment はアプリケーションが通信相手や文脈に応じて定義し、その文脈が終われば閉じられる。状態を一切保持しない端点は、状態容量をゼロに設定できる。したがって永続化は、現在のメッセージを解凍するための必須条件ではない。

より重要な規則は解凍後にある。アプリケーションは復元されたメッセージを受け取り、プロトコルと通信文脈に沿って認証できる。アプリケーションが有効な compartment 識別子を付与する意思を示したときに限り、SigComp 層はその compartment に新しい状態を作り、圧縮側へフィードバックを渡す権限を得る。十分な確信がなければ、有効な識別子は渡されない。その場合、UDVM は終了し、要求された状態を保存せず、フィードバックも転送しない。

意味に関する判断をデコーダーの外に置いた点が肝心だ。UDVM は指定された資源境界内でバイト列を復元できても、シグナリングが真正か、期待されたダイアログに属するか、後続の圧縮に影響してよいかまでは判断できない。アプリケーションは文脈を持ち、最後の判断を保持する。RFC 4896 は後に認証と状態作成の境界を明確にした。解凍結果は、それだけでは信頼の判断にならない。

既存状態へのアクセスには別の門がある

順序には難しさがある。アプリケーションは認証のために解凍後の内容を見る必要がある一方で、解凍自体は既存状態を必要とするかもしれない。SigComp は既存状態へのアクセスを、解凍後のアプリケーション承認とは別に扱う。状態識別子は状態バイト列のハッシュから導かれ、受信側は UDVM に状態を見せる前に識別子を確認する。既存状態を読む検査を通っても、新しい状態を残す段階では引き続きアプリケーションの許可が必要だ。

「このメッセージは確立済みの圧縮状態を読めるか」と「認証後の内容から永続状態を作れるか」は、異なる証拠を使う別の問いである。混同すると規則が矛盾しているように見える。前者は制御されたアクセスで解凍を成立させ、後者はアプリケーションが内容を知った後の判断を待つ。

後続文書は周辺の問題を補った

RFC 3321 は拡張操作と確認機構を加えた。不可靠なトランスポートでは、送信側が相手の状態を前提にする前に確認が問題になる。RFC 4077 は解凍失敗を知らせる否定応答を定義する。RFC 5049 は SIP に SigComp を適用するための要件を示すが、その SIP 固有の規則をすべてのアプリケーションに一般化してはいけない。RFC 4464 は利用者向けガイド、RFC 4465 は厳しい条件のテスト集だ。説明、失敗通知、アプリケーション別のプロファイルは必要だったが、それらだけで普及や測定済みの効果が証明されるわけではない。

RFC 3320 の長く残る貢献は権限の分割にある。メッセージは制限付きの計算を要求できる。アプリケーションは、その意味を後続メッセージに影響する記憶にしてよいかを決める。この二段階を分けることで、資源と信頼の境界が可視化され、「解凍できた」が暗黙に「保存してよい」へ変わるのを防ぐ。

出典