要約

  • RFC 3321 は、遠隔デコンプレッサーで状態が確立したことを明示的な確認で圧縮側へ知らせ、不可靠な転送路でも動的圧縮を進められるようにした。
  • ただし確認後も、有限メモリと保持優先度の規則によって状態は削除され得た。確認済みという履歴と、現在参照可能という事実は同じではない。

正しい実装同士でも知識はずれる

2007 年の RFC 4896 には、障害の原因を実装ミスだけに求められない例がある。共有モードで最低保持優先度の状態が複数作られると、新しい状態が古い状態を予想より早く押し出す場合がある。デコンプレッサーは規則に従って削除する。コンプレッサーも受け取った情報に従って参照する。それでも、コンプレッサーが「まだある」と考えた状態は、相手側では既に消えている。

この例は RFC 3321 の明示的確認を読むうえで重要である。確認は、ある状態が遠隔側で正常に保存されたことを伝える。動的圧縮では、圧縮側が未確認の状態を基準にすれば、遠隔 UDVM は元のメッセージを復元できない。そのため確認は必要な証拠だった。

しかし、その証拠が示す時点は作成時である。後にどの状態が作られ、利用可能なメモリがどう変わり、保持規則が何を削除したかまで固定するものではない。正しい確認が、時間の経過によって現在の判断材料として不十分になる。

メッセージ到着と状態存続は別の出来事

RFC 3321 は 2003 年 1 月に Informational として刊行された。RFC 3320 の UDVM 命令で実装できる拡張として、明示的確認、共有圧縮、セッションをまたぐ状態、利用者別辞書、チェックポイントなどを説明する。実運用での普及率や圧縮率を測定した文書ではない。

文書は、TCP のような信頼できる転送なら以前のメッセージの受信は保証され、不可靠な転送では SigComp 自身の明示的確認が必要だと説明する。この対比は、TCP が状態の寿命まで保証するという意味ではない。転送が証明するのはメッセージ到着である。アプリケーションが保存を許可したか、保存領域があったか、後の割り当てで削除されなかったかは別の層の事実だ。

前の RFC 3320 記事は、解凍成功と永続状態を作る権限を分けた。本稿はその次の時点を扱う。アプリケーションが作成を認め、遠隔側が保存を確認したあと、その確認をいつまで現在の状態として利用できるのか、という問題である。

チェックポイントにも削除規則がある

RFC 3321 は、参照した状態が存在しない三つの経路を挙げる。状態を作るメッセージが失われた場合、作成時にメモリが足りなかった場合、そして一度作られた状態が後にメモリ不足で削除された場合である。

チェックポイント状態は、同じコンプレッサーが送ったなかで最も高い保持優先度を与えられ、明示確認も要求される。それでも不死ではない。後のチェックポイント作成が領域を使えば、以前のチェックポイントが削除された可能性を考慮しなければならない。

そこでコンプレッサーは、遠隔側が広告する state_memory_size を追跡する。この値から、過去のチェックポイントが押し出されたかを推論できる。しかし値は状態一覧ではない。特定の識別子が現在存在するかを直接回答せず、容量、作成順、年齢、優先度を組み合わせるための制約を与える。

暗黙の確認は、対象より長く届くことがある

共有圧縮では、受信した非圧縮メッセージを共有状態として保存し、逆方向の圧縮に利用できる。RFC 3321 は、共有状態が実際に使われたことから、別の状態が遠隔側に作られたと暗黙に確認する最適化を説明する。個別の acked_state_id を省略できる点が利点だった。

ところが、告知情報が正常に転送されたあと、対象状態がメモリ不足で破棄される可能性があると同じ文書が警告する。告知を受け取った事実と、告知対象が利用時まで残った事実の間に隙間がある。state_memory_size を考慮しなければ、その隙間は次の解凍失敗として現れる。

さらに、返された部分状態識別子は、確認済み状態、共有状態、あるいはグローバル状態を表し得る。何を指すかは実装が推定し、基本 SigComp 実装は拡張識別子を無視できる。パケット上に値があるだけでは意味は完結しない。ローカルの対応表と、どの拡張機構を用いたかが必要になる。

65535 は最強ではなかった

RFC 4896 は保持優先度の順序を明確にした。65535 は見た目に反して最低であり、その次が 0、1 から 65534 と続く。優先度は状態バイトそのものだけでなく、compartment が持つ参照に結び付く。

最低優先度状態が複数あると、コンプレッサーはどれが残ったか確信できなくなる。新しい状態の作成により、古い状態が規則どおりに削除されても、相手側にはその詳細が直ちに伝わらないからだ。RFC 4896 は、存在を確信できない状態を参照すべきではないとする。状態の広告は、年齢と保持優先度の削除規則が定める寿命についての約束であって、永久保存の約束ではない。

RFC 4077 の STATE_NOT_FOUND NACK は、参照した状態が見つからないという新しい証拠を返す。通常、受信したコンプレッサーは以後その状態を使わない。これは以前の確認が虚偽だったという判決ではない。作成後に削除されたという時間順序を完成させる記録である。

RFC 3321 が残した教訓は、確認を弱く見ることではない。確認が何を、いつ証明したかを正確に保つことである。「作られた」「削除規則上は残るはずだ」「いま取得できる」「その状態で解凍できた」は四つの異なる観測だ。一つの確認フラグに畳み込めば、正しい実装同士で起きるずれさえ説明できなくなる。

Sources