要約

  • RFC 1477のプロトタイプは、四つの管理ドメインからなる環状構成で、ゲートウェイ停止と通過ポリシー変更の双方に対応し、報告上はTelnetセッションを維持した。
  • ただしプロトタイプは送信元ポリシーとドメイン間の複数ポリシーゲートウェイを意図的に省き、マッピングサーバーも使わなかった。実験の成功は、その外側まで証明しない。

消えなかった端末の会話

RFC 1477の実験では、送信元ドメインSと宛先ドメインDの間に、通過ドメインT1とT2が置かれた。四者は環を作るので、SからDへ二つの経路がある。Telnetを始めると、S側のポリシーゲートウェイにいるパスエージェントがルートサーバーへ問い合わせ、得たポリシールートを使ってパスを設定した。

最初の試験では、利用中のT1上にあるゲートウェイのIDPRプロセスを終了させた。両隣のゲートウェイが接続断を見つけ、ルーティング情報を流し、残ったパス区間を解体する。Sのパスエージェントは新しいルートを求め、今度はT2を通るパスを作る。その間もTelnetセッションは維持された、と報告されている。

次は装置を止めず、T2の通過ポリシーを変更した。SからDへのトラフィックを拒む設定にすると、変更情報が配布され、T2のパスが解体され、復旧したT1側へ付け替えられた。ここでもセッションは残った。

この結果が有力なのは、単なる到達確認ではないからだ。プロトタイプには観測機構が組み込まれ、隣接接続、通過ポリシー、リンクステート情報、生成されたルート、パス制御メッセージ、パス状態の変化を追跡できた。設定変更から経路の撤去と再構築までを、複数の記録でたどれた。

しかし、よい観測ほど境界を明記しなければならない。

速く動かすために空けた二つの席

RFC 1477は、プロトタイプがIDPR機能の「大部分」を備えた一方、すべてではなかったと書く。動くソフトウェアを早く得るため、送信元ポリシーへの対応と、二つのドメインを複数のポリシーゲートウェイで結ぶ構成を意図的に外した。

送信元ポリシーは、通過ポリシーの別名ではない。通過側の管理者は、自ドメインの資源を誰がどの条件で使えるかを決める。送信元側は、自分のトラフィックが必要とするサービスや通過条件を表す。実験は通過ポリシーを書き換えたが、未実装だった送信元ポリシーの評価を試したことにはならない。

同じドメイン対の間に複数のゲートウェイがある場合も、単一接続とは異なる。選択、冗長性、状態のまとめ方、片方だけが故障したときの修復が加わる。四ドメインの環は二つの大きな迂回路を比較できたが、一つの境界に複数の出口がある分岐は実装していなかった。

省略そのものは欠陥とは限らない。最初の実装を小さくすれば、設計上の仮定を早く実行にさらせる。重要なのは、後からプロジェクト名だけを見て、空けた席にも試験済みの印を付けないことだ。

テストベッドが与えた現実性

開発は1990年夏に始まり、完成したプロトタイプの実験は1991年2月に始まった。USCはSPARC1+をイーサネットで結び、構成を自由に変えられる実験網を用意した。SAICはSpartaとMITREのSun3を、Alternet上の9.6 kb/s SLIPとDCA EDNテストベッド上のX.25経路で接続した。BBNとISIのSPARC1+はDARTnetとTWBnetで結ばれた。

当時の実機と複数の広域技術を使った点は重い。紙上の模擬ネットワークではない。一方、主要なシナリオは四ドメインの単純な環であり、二つの通過ドメインは当初、アクセス制限を持たなかった。

さらに、マッピングサーバーは使用していない。アドレスとドメインの対応表を各ポリシーゲートウェイへ設定した。これによりルート生成は試せるが、マッピング情報の配布、更新、衝突、欠落、古さは試せない。

テスト用の固定表は、依存関係を一時的に閉じる道具である。固定表の答えが正しいという条件下で、下流の動作を観測できる。固定表の存在をもって、動的サービスの実装証明にしてはならない。

「全部」の参照先

報告は、この単純な実験群がプロトタイプの主要機能をすべて試し、ネットワークの変化に素早く正確に適応できることを示したと結ぶ。ここで「すべて」が指す対象はプロトタイプである。

RFC 1478のアーキテクチャとRFC 1479のプロトコル仕様は、より広い対象を持つ。要求側の文書に機能が書かれていても、実装側の報告が省略を明記しているなら、要求は実行記録の代わりにならない。

Telnetセッションが維持されたという文も同様だ。アプリケーションの連続性を示すが、パケット損失数、収束時間の分布、何回繰り返したかは掲載されていない。他のアプリケーション、規模、障害順序、ポリシーの組合せまで無停止だったとは言えない。

一回の観測を一回の観測として残すことは、過小評価ではない。再現できる主張の最小単位を守ることである。

数字のない性能評価

USCとSAICの参加者は、パス設定とメッセージ転送の処理量を測った。IPカプセル化を使うIDPR転送と通常のIP転送を比べ、完全性・認証値を計算しない場合とRSA/MD4を使う場合も比べた。

結果は「encouraging」とされたが、数値はRFCに載っていない。入手先の連絡先が示され、同時に、最適化へ十分な時間を使っていないため他実装へ盲目的に外挿しないよう警告された。

ここから数値を作ることはできない。測定対象、実施の事実、著者の評価、外挿禁止という四点までが証拠である。性能の優劣や比率は、元の表がなければ未確定のまま残る。

gatedは次の検証入口だった

1992年にはSRIが加わり、SAIC、BBNとともにIDPRをUNIXのgatedプロセスへ統合した。RFC 1477は、この版が完全なIDPR機能と設定インターフェースを備え、複数プロセスの試作版より単一プロセスとして効率的だったと述べる。無償で入手でき、UNIX機があれば実装費なしに実験できた。

それは採用の証明ではなく、採用を試せる条件の成立である。文書は、実運用の制約と実トラフィックの要求を持つネットワークへ持ち込み、経験を得ることを次の目的にした。発行時点では選定地点でパイロットとデモが進行中だった。

公開、取得、インストール、有効化、実トラフィック、継続運用は別々の状態だ。「パイロット中」は開始の記録であり、完了判定ではない。

文書上の状態も分ける必要がある。RFC 1477のRFC Editor記録では、題名にProposed Standardとあっても文書自体はInformationalである。RFC 1478の記録とRFC 1479の記録は各文書の身分を保存し、RFC 2026は標準化過程の語彙を説明する。どのラベルも稼働状況を自動的に証明しない。

成功を大きく見せないことが成功を守る

RFC 1102は管理領域をまたぐポリシールートの組み立てを論じ、RFC 1104はルーティング、パケット処理、資源配分、会計を分けた。RFC 1477に固有なのは、設計思想そのものより、実装と観測の範囲を読める記録である。

Heng LuのRunning-Code Primacy、Minimum Initial Specification、Reality Layersという視点を重ねると、評価は単純になる。動いたコードは提案より強い。しかし動かなかった機能について、動いたコードは証言できない。

四ドメインの環を迂回しながらTelnetが続いたことは、十分に興味深い。そこへInternet全体の成功まで足す必要はない。省略を保存することが、実験の価値を最も長く守る。

出典