要約

  • RFC 1553 は30オクテットの IPX ヘッダーを1〜7オクテット、36オクテットの NCP/IPX ヘッダーを1〜8オクテットにできた。省略された情報は送受信側の対応するスロットに残った。
  • 一般の IPX では Confirmed Initial と Confirm が文脈を確立してから圧縮パケットを送った。NCP の未確認経路は、シーケンスと再送が文脈喪失を検出できる場合に限られた。
  • スロット番号まで省くには、受信エラーを解凍器へ必ず通知する必要があった。廃棄後は明示番号が届くまで暗黙スロットのパケットも廃棄した。

一枚の欠落で「前回」が二つになる

スロット番号を省いたパケットは「前のパケットが選んだスロットを使え」という意味だった。そこで前のパケット自体が失われれば、送信側の前回と受信側の前回は一致しない。小さなヘッダーの危険は、その一枚にあるのではなく、二つの履歴が静かに分かれることにあった。

RFC 1553 は1993年12月に Standards Track として発行され、現在は Historic である。CIPX と呼ばれた一般方式は30オクテットの IPX ヘッダーを1〜7にした。必須の別方式は NCP の要求・応答型 0x2222 と 0x3333 を対象に、36オクテットの NCP/IPX を1〜8へ縮めた。その他の NCP 型も一般 IPX 圧縮は利用できた。

CIPX の交渉後は、通常形式で送る IPX にもフラグオクテットが付いた。各パケットが独立した省略記号を選ぶのではない。両端が保存してきた状態の中で読む形式である。

ここで1オクテットを「小さなヘッダー」と呼ぶだけでは不十分である。実体は共同履歴への索引だった。索引は本文より短くできるが、参照先の版が一致している場合にしか意味を持たない。ワイヤ上の情報量が減ったぶん、二台の装置はワイヤ外でより多くの事実を保持した。

文書上の地位も実行の証拠とは別である。1993年の Standards Track は当時の標準化経路を、現在の Historic は後の分類を示す。それだけでは、特定製品が実装したことも、二つの表を正しく同期したことも証明しない。

消えたフィールドは表への参照だった

圧縮器は新しいヘッダーを送信スロットの完全なヘッダーと比べ、変化だけを送る。解凍器は受信スロットへ変化を適用して完全形を復元する。1オクテット形は、受信側が残りをすでに正しく持つ場合だけ正しい。

したがって圧縮フレームだけの保存では復元内容を証明できない。スロット表、その世代、そこへ至った遷移が要る。データ圧縮も併用する場合、送信はヘッダーの後にデータ、受信はデータの後にヘッダーという逆順も証拠鎖に含まれた。

観測点が違えば、同じ通信でも記録される対象が変わる。データ圧縮を解く前のバイト列と、ヘッダーまで復元した後のパケットは同じ証拠ではない。「解凍成功」という一語にまとめると、データ変換、スロット選択、ヘッダー再構成、アプリケーション受理の境界が消える。

通常形式も状態会話の外には出なかった。CIPX 交渉後の未圧縮 IPX はフラグを伴い、より多くの情報を再びワイヤへ載せる退避路として働いた。完全形を一度見たという事実だけで、古い世代が自動的に無効になるわけではない。

Confirm が記憶を共有事実にした

一般 IPX の最初の文脈パケットを失っても、通常ヘッダーにはそれを確実に示す輸送シーケンスがない。そこで Confirmed Initial がスロット番号と1オクテット ID を送り、相手の Confirm を受けるまで、その関連に基づく後続圧縮を始めなかった。

スロットを別ヘッダーへ割り当てると ID を増やした。スロットと ID は場所ではなく世代を指した。ID が「十分長く」一意である期間は、速度、往復時間、負荷に左右された。

スロット番号は「どこを見るか」を示し、ID は「その場所のどの時代を見るか」を示した。同じ場所に新しい接続を入れた後、古いパケットが遅れて届くことはあり得る。世代がなければ、その遅延は新しい文脈の正当な変更に見えてしまう。

1オクテットの ID はいつか周回する。したがって永続的な身元ではなく、古いパケットが消えるまでの運用窓を守る仕組みだった。リンクが速く、往復が長く、再割当てが頻繁なら「十分長い」の条件も変わる。

確認を待つ間、送信側がすべてを停止する必要はなかった。同じスロットと ID で同じヘッダーに属する新しいデータを再送でき、ID を増やせば別ヘッダーへ再割当てもできた。前進の自由は残しつつ、意味の変更には識別可能な世代を要求したのである。

NCP の Unconfirmed Initial は限定例外である。要求・応答のシーケンスと再送が壊れた文脈を発見できるため即時圧縮を許したが、番号が厳密に1増えていなければ新たな Initial が必要だった。証拠を捨てたのではなく、上位の回復機構を利用した。

この例外は、単なる高速モードとして他の通信へ移せない。NCP で確認待ちを省けたのは、要求・応答に別の検出信号があったからである。同じ順序性と再送性を持たない流量から Confirm だけを外せば、速度の利益は残っても、破綻を限定する根拠はなくなる。

反対に Confirm も万能な成功証明ではない。特定世代が受信側に成立したことを示すだけで、その後の損失、表の継続的一致、トランスポート回復、利用者の結果までは語らない。「交渉済み」「確認済み」「復元済み」「処理成功」は別々の状態である。

エラー通知が形式の一部になった

スロット番号圧縮は既定で無効だった。有効にできるのは、PPP 層が誤りまたは廃棄を一件残らず解凍器に伝える場合だけである。通知を受けた解凍器は、明示スロットが来るまで番号なしパケットを捨て続けた。下位層で観測した損失を上位へ渡すことが、省略の正しさを作った。

索引が壊れた後は、正しいビット列でも読めない

後続パケット自体に誤りがなくても、番号がなければ捨てる必要があった。欠けたのは現在のパケットの完全性ではなく、「直前のスロット」という参照先の共有性である。送信側は切替えを見たが受信側は見ていない。同じ索引省略が二つの場所を指す。

推測がたまたま当たる場合はある。しかしプロトコルは偶然を受領証にできない。明示番号が来るまで廃棄する規則は、もっともらしい誤復元より、見える損失を選んだ。短い表現の利益を守るために、受信側は一時的に利用可能に見えるデータを拒否したのである。

そのためリンク層の通知は運用ダッシュボードの付加情報ではない。暗黙索引という形式を成立させる入力だった。月末に総損失数が分かっても遅い。「直前」を管理する解凍器が、どの時点で履歴の鎖が切れたかを順序どおり知る必要がある。

復帰時間は次に明示スロットが現れるまで続く。送信側が暗黙形を使い続ければ、短く送れたパケットが受信側で連続して捨てられる。ヘッダー比率だけを測ると、この失敗さえ高効率に見える。

予約された先頭値により、CIPX は従来の 0xFFFF チェックサムで始まる通常 IPX と区別できた。相手が再起動して通常 IPX に戻れば、古い表で解釈せず再交渉する。未知のパケット型や依存フラグには Reject を返し、拡張差を沈黙した状態汚染にしない。通常形式への退避も残った。

PPP では IPXCP が受信能力を方向ごとに要求したため、双方向には二つの要求が必要だった。IPX-WAN では同じスロット数と受理オプションを両方向で使う対称結果になった。しかし交渉済みという記録だけでは、個々の Initial、表の一致、復元バイト、アプリケーション結果は証明できない。

方向別の合意と対称の合意は同じ記録ではない

PPP で A から B への圧縮が成立したなら、それは B がその方向の受信能力を求め、受け入れたことを示す。逆方向は別の要求である。単一の「CIPX 有効」フラグは、片方向の事実を双方向へ拡張してしまう。

IPX-WAN は両方向に同じスロット数と共通オプションを与えた。最終形は対称でも、そこへ至る選択と、その後の各 Initial は別に残る。パラメーターが一致しても、世代が食い違うことも、アプリケーションが回復しないこともある。

交渉、文脈成立、ヘッダー復元、トランスポート回復、利用結果は連続しているが同一ではない。前段の成功から後段を推定すると、短いパケットが行った省略を、監視記録でもう一度繰り返すことになる。

2対1は観測値ではなく、仮定を見せた計算だった

約2対1という比率は、26オクテットのデータ、30の元ヘッダー、2の圧縮ヘッダーを仮定した計算であり、配備測定ではない。CIPX は IPX の基本的な安全性を大きく変えないという記述も、当時の文書評価であって全実装への保証ではない。

計算は明快である。26と30で56、26と2で28になる。しかし実際のパケット長分布、Initial と Confirm の頻度、スロット再割当て、Reject、通常形式、明示スロットを待つ間の廃棄は含まれない。CPU負荷、回復遅延、アプリ再送も数えていない。

したがって短い平均ヘッダーと悪化したサービス結果は両立し得る。文脈不明で捨てられたパケットも、ワイヤ上では少ないバイトで送られている。上位層が再送すれば、節約した以上の通信が戻る可能性もある。運用上の比率には、標本、測定点、期間、損失条件、成功の定義が要る。

安全性の一文も同じように限定して読むべきである。1993年の文書が IPX の基本安全性を大きく変えないと評価したことは、後の全実装、異常入力、層の組合せ、現代の脅威への保証にはならない。

凍結資料には、固有名のある CIPX 配備、導入規模、パケット資料、相互運用試験、事故、利用者結果はない。確認できるのは規則と文書系譜であり、1オクテット形の普及や特定製品の回復ではない。

短い索引には長い受領記録が要る

再現可能な判断は、誰がどの方向を交渉し、どのオプションとスロット数が受理されたかから始まる。次に、スロットの割当者、世代 ID、完全な Initial、一般 IPX で必要な Confirm を保存する。NCP の未確認経路なら、その例外を支えたシーケンスと再送の証拠が要る。

リンクエラー通知、受理した順序、明示または暗黙のスロットは、解凍器が当時どの表を使う資格を持っていたかを示す。長さとチェックサムがワイヤ、差分、旧状態のどこから来たかも区別する。復元ヘッダーのハッシュの後に、解凍判断、トランスポート回復、アプリケーション結果を別々に置く。

最終的な完全パケットだけでは足りない。同じ復元結果が異なる履歴から生じることも、同じ1オクテットが異なる表で別のヘッダーになることもある。世代が上書きされ、損失時系列が消えれば、後から正しいアルゴリズムを適用しても当時の参照先は証明できない。

不可逆性はここにある。実装は更新でき、オプションは無効化でき、リンクは再交渉できる。しかし消した参照履歴は後で生成できない。メッセージから情報を除く最適化は、その情報を移した場所で、より明確な受領証を増やさなければならない。

残すべき受領記録は、交渉者と方向、オプションとスロット数、割当者と世代 ID、完全 Initial、必要な Confirm、リンクエラー通知、受理順序、明示・暗黙スロット、長さとチェックサムの由来、復元ヘッダーハッシュ、解凍判断、輸送回復、アプリケーション結果である。短くなった線上の記録を、長い状態記録が支えていた。

出典