要約

  • RFC 1306 は、経路探索後にカーネルが外部スイッチへの接続要求を生成できた Cray プロジェクトを報告している。
  • 未完了の接続でデータ転送を試みても回線を自動起動してはならず、TCP は回線が完了するまでその経路で送信しない。
  • 初期実装では、データ未送信のまま接続待ち中に TCP 再送タイマーが後退したため、後の実装では確立待ち用の別タイマーが導入された。

分析

要求を出せることと、資源を持つこと

この実験で特別な知識を持つのは送信元ホストだった。そこでは、ある通信が要求型の回線交換リンクを必要とすること、そしてどの制御装置に知らせるべきかを知っている。経路探索はその知識を呼び出し、カーネルはスイッチ制御メッセージを生成できる。だが、ここで得られるのは相手側に対する依頼であって、相手側の資源そのものではない。

RFC 1306 は、スイッチが要求を受ければ、可能な場合に接続を作ると記す。この「可能な場合に」という条件は、実装上の余白ではない。ホストが観測できる範囲と、外部制御装置が処理する範囲を分ける言葉である。経路項目から分かるのは、どこに要求を出すかであり、回線の確立、容量、受理を先取りしてはならない。

経路エイリアスもこの限界を示す。複数の代替経路を送信元に既存の経路インターフェースで見せられるが、文書はその政策と経路選択の問題を対象外にしている。選択肢が表示されることは、どの選択肢が許可されるか、実現するか、誰に結果責任があるかを決めない。

未完了の経路にはデータを乗せない

文書の設計原則は明快である。不完全な接続に対する転送試行が回線を自動的に起動してはならない。回線が完了するまで、TCP はその経路上でデータを転送してはならない。これはアプリケーションの最初の送信希望を、外部ネットワークへの無言の資源要求に変えないための境界である。

ここで区別すべき状態は多い。ホストは要求を送ったかもしれない。制御装置はまだ応答していないかもしれない。回線は確立中か、拒否されたかもしれない。最初のセグメントはまだ送られていないかもしれない。これらを一つの「接続」表示にまとめると、障害の場所も証拠の種類も消える。

RFC 1306 は接続要求と接続中止のメッセージを述べる。中止できるという事実は、要求が永続的な状態でも契約でもないことを示す。要求は意思表示であり、利用可能なデータ経路の受領書ではない。

再送タイマーに、まだ起きていないことを語らせない

最初のカーネル実装では、スイッチ接続の確立中に通常の TCP 再送タイマーがバックオフしうるという問題があった。まだデータは送られていない。後の実装は、その確立期間を別のタイマーで扱った。

タイマーは汎用的な失敗判定器ではない。再送タイマーが本来意味を持つのは、すでに送られたデータへの期待した反応が欠ける場合である。外部回線の準備待ちを同じ時計で数えれば、制御待ちを送信済みデータの損失や遅延に見せてしまう。

別タイマーは回線を保証しない。待機という状態を正しく名前付けするだけである。しかしそのだけが重要だ。観測装置は、観測していない送信結果を代弁してはならない。確立待ちは確立待ちとして記録され、データ面の証拠はその後に別途得られなければならない。

1992 年の報告が残す境界

RFC 1306 は 1992 年 3 月の情報提供 RFC であり、現代の通信事業者や製品を説明する標準でも配備調査でもない。そこから読めるのは、結果を早送りしない作法である。経路選択、要求、外部処理、回線完了、最初の送信、応答の観測、サービス上の結果は別々の節目である。

経路が選ばれても回線は証明されない。回線が完成しても配送は証明されない。配送があっても利用者の目的達成は証明されない。各段階に固有の証拠を求めることで、制御メッセージは自分の範囲を超えない。

出典

RFC 1306 は 1992 年のプロジェクト経験を記すものであり、現在の配備、経路の権限、容量の権利、回線完了、パケット配送、利用者の結果を立証しない。