Summary
- RFC 5225 の
co_repairは、復元した非圧縮ヘッダーチェーンを CRC-7 で検査し、適用される制御フィールドを独立した制御 CRC-3 で検査する。後者が今回の復号に使われない場合があるため、一方の成功は他方を証明しない。 - 経営上の要点は、現在の出力を受理する判断、永続状態を進める判断、肯定応答を返す判断を分離し、それぞれが参照した証拠の範囲を残すことである。
成功は一つの時刻に閉じていない
ある圧縮パケットのヘッダーが正しく復元され、CRC-7 も一致した。観測点をこの瞬間だけに置けば、処理は成功である。しかし、圧縮の効率を支える共有コンテキストは、このパケットだけのために存在するのではない。更新された状態は、まだ到着していないパケットの解釈に使われる。
RFC 5225 の co_repair には、復元したヘッダー全体に対する CRC-7 に加え、control_crc3_encoding がある。制御 CRC-3 は、適用される制御フィールドを連結したものに対して計算される。二つの検査は重複ではない。観測している対象が異なる。
規格は理由も示す。更新対象の制御フィールドが、そのフィールドを運んだヘッダーの復号に常に使われるわけではない。その場合、CRC-7 は制御フィールドの更新を覆わない。現在の復号が成功し、肯定的なフィードバックが送られても、制御状態だけが誤っているという組み合わせが成立し得る。
コンテキストへの信頼には段階がある
RFC 5225 の Repair Context は、出力と状態を同一視しない設計をよく表している。パケットは復号できているが、展開側はコンテキスト全体をまだ信用していない。規定の CRC-7 または CRC-8 を持つパケットによって、Full Context へ戻ることができる。
一方、順序上遅れて届いたパケットは正常に復号されても状態を更新しないことがあり、そのパケットへの ACK を控えることもできる。コンテキスト損傷の検出方法は実装依存である。つまり、同じ「復号成功」でも、状態機械に対して同じ意味を持つとは限らない。
これは不確実性を隠す設計ではなく、不確実性を状態として保持する設計である。現在の出力に関する事実と、将来の処理基盤に関する判断を分けることで、回復経路が残る。
検査結果には必ず目的語がある
「CRC が通った」という記録だけでは監査に足りない。どの入力、どのフィールド、どの再構成物が計算範囲に入ったのかを示して初めて、結果の意味が定まる。
co_repair の CRC-7 が述べるのは復元された非圧縮ヘッダーチェーンについてであり、制御 CRC-3 が述べるのは適用対象の制御フィールドについてである。どちらも暗号署名ではなく、送信元の身元、アプリケーションへの到達、音声品質、特定製品の正しさを証明しない。
監査記録には、検査対象、使用した旧状態、変更予定のフィールド、計算範囲、結果、その結果が許可した操作を残すべきだ。範囲のない合格表示は、別の対象に結論を貸し出す入口になる。
遅延故障は過去の成功から始まる
現在の出力が壊れていれば、原因と症状は近い。現在の出力は正しいが、状態遷移だけが壊れている場合、症状は後続パケットで現れる。肯定応答が送られた後なら、双方は誤った共通認識をさらに利用しているかもしれない。
障害調査は症状が出た最後の処理に引き寄せられる。以前の成功ログは要約され、途中の状態変化は削除され、再試行は差異を拡大する。ソフトウェアを戻しても、旧経路が作った派生状態が残れば回復は完了しない。
必要なのは単なるエラー率ではなく、因果をたどれる記録である。現在の出力を受理した証拠と、将来用の状態を進めた証拠を別に保存しなければならない。
三つの判断を一つの成功表示から解放する
状態を持つ処理では、少なくとも三つの判断がある。現在の結果を使うか。内部状態を次へ進めるか。相手に肯定的なフィードバックを返すか。運用を単純にするために同じ真偽値へ束ねると、限定的な観測が全面的な保証に変わってしまう。
現在の結果を利用しながら、付随する学習、キャッシュ、ポリシー、制御状態の更新を拒否することは可能である。逆に、内部状態の整合だけでは利用者の結果を証明できない。各判断に別の証拠と責任者を割り当てることが、複雑さではなく回復可能性を生む。
証拠が示していないこと
RFC 5225 は、特定の端末、モデム、無線網、事業者、製品が制御状態を誤って扱ったと報告する文書ではない。現在の導入率、障害件数、パケットトレース、体感品質も示していない。IANA の識別子登録は、実運用の証拠ではない。
また、別の CRC が存在するからといって、すべての修復パケットで誤更新が起きたわけではない。設計上の防護が必要な理由と、現実に事故が発生したという主張は分けなければならない。
成功記録を二枚に分ける
重要な状態処理には、相互参照できる二枚の記録を残す。出力側には入力、復元処理、検査範囲、結果、配送境界を記す。状態側には旧状態の識別子、変更フィールド、独立検査、採否、返したフィードバック、新状態の識別子、継続を許可した主体を記す。
出力は成功したが更新を拒否した場合、更新は整合したが配送を確認できない場合、遅着入力で状態を進めなかった場合、ACK を控えた場合、修復や再確立を要求した場合も残す。例外は成功率を汚すものではなく、成功の適用範囲そのものである。
Lu Heng が重視する実行事実、現実、代理関係の責任は、この境界に直結する。組織名や規格名ではなく、「現在の証拠で将来の状態を進める」と決めた主体を特定できなければならない。
Sources
- RFC 5225:ROHCv2 プロファイル
- RFC 4995:ROHC フレームワーク
- RFC 4997:TCP 用 ROHCv2 プロファイル
- RFC 3095:ロバスト・ヘッダー圧縮
- RFC 4224:ROHC RTP 実装上の課題
- RFC 4815:RFC 3095 の訂正と明確化
- RFC 3843:IP 用 ROHC プロファイル
- RFC 4019:UDP-Lite 用 ROHC プロファイル
- IANA ROHC プロファイル識別子
- Lu Heng:製品は主張ではなく現実
- Lu Heng:稼働するコードの優先
- Lu Heng:インターネット・ガバナンスの代理問題
追加の標準記録
会員向け解説
プロフィールの詳細
適切な会員レベルでログインすると、解説全文と出典メモをご覧いただけます。
Strategic Circle 限定
Strategic Circle
すべての読者に公開されています。参加してログインすると プロフィール解説 を閲覧できます。
Strategic Circle に参加Leadership Alliance 会員限定
Leadership Alliance
対象となる IP 資産の所有者・管理者向けです。ログインすると Leadership Alliance の解説を閲覧できます。
Leadership Alliance に参加
