要約

  • RFC 891のHELLOは、経路選択用の往復遅延を測り、その経路に結び付いた時計オフセットも伝えたが、二つの更新条件は同一ではなかった。
  • 最小遅延の経路は時刻観測の搬送路であり、親時計を選出しなかった。親のホストIDは設定項目CLOCK-HIDで指定された。
  • 送受信HELLOの同一長、保持期間、日付の有効性、時計の漸進補正と跳躍処理が、受信・経路採用・時刻補正を別の出来事にした。

時刻同期には正しい時計が必要で、遅延測定にも正しい時計が必要だとすれば、起動時に循環が生じる。RFC 891のFuzzballは、まず時計の一致を前提としない往復測定でこの循環を切った。

対象は最大256のホストとゲートウェイからなるDCNローカルネットだった。PDP-11やLSI-11のFuzzballが、ポイント・ツー・ポイントとマルチポイントの回線で結ばれていた。各ノードがパケット交換、ゲートウェイ、サービスホストの機能を持ち、別建てのローカル経路制御者はいなかった。

そのため各ホストのHost Tableが重要になる。宛先ごとに出力プロセス、測定した往復遅延、時計オフセット、更新時刻、生存カウンタを持った。外部ネットワーク用のNet Tableは分離され、通常は設定が所有し、GGPやEGPのプロセスだけが必要に応じて更新した。

往復値は同期前にも使えた

同一ネット内のHELLOはIPプロトコル番号63を使い、Host Tableの遅延とオフセットを運んだ。現在のIANA Protocol Numbersにも63は「any local network」として残る。これは番号割り当ての記録であり、DCNの現行利用を示す統計ではない。

測定は、受信したHELLOの状態と次に送信するHELLOを組み合わせた。送信間隔が一定でなくても、両端の時計がずれていても成立し、HELLOが失われたり反射されたりしても方法全体は壊れなかった。

ただし、形式とチェックサムを通過したメッセージの全項目が採用されるわけではない。精密な時刻計算には、最後に送信したHELLOと受信したHELLOの長さが等しいことが必要だった。長さが違えば、経路だけ更新してオフセットを据え置くことができた。

一つのパケットを二つの制御ループが読む。片方が採用しても、もう片方は拒める。この非対称性が設計を安全側に保った。

「近い」は「正しい時刻の所有者」を意味しない

候補経路の値は、隣接ノードまでの往復遅延と、そのノードが宛先について広告した遅延の和だった。新経路は現在の経路を設定された幅だけ上回って初めて切り替えられた。記載された実装例では約100ミリ秒のしきい値、120秒の保持、30秒の最大経路遅延が使われた。これらは歴史的な実装値であって普遍定数ではない。

採用した経路には、その経路の時計オフセットも付随した。ここから「最も近い時計が親になる」と読むのは誤りである。親時計のホストIDはCLOCK-HIDに設定されていた。

遅延アルゴリズムは時刻情報をどこから運ぶかを決める。誰の時刻に従うかは設定が決める。さらに、親のオフセットであっても日付が有効でなければならず、ローカルの補正処理を通らなければ時計を動かせない。

戻り方向では出所を数字に刻んだ

ある回線から学んだ経路を同じ回線へそのまま返すと、互いの広告を根拠にしたループが生まれる。RFC 891は、その方向の値をMAXDELAYに置き換えた。RFC 2453は後年、スプリットホライズン、ポイズンリバース、トリガードアップデート、無限大へのカウントという比較しやすい語彙を与えた。

これはHellospeakからRIPへの直接系譜を示すものではない。共通する教訓は、経路値から入力回線を消すと、他者から聞いた話が自分の独立した観測に見えてしまうことだ。

生存カウンタと保持期間も履歴を残した。隣接ノードが見えなくなった瞬間に古い状態を完全な空白へ戻さず、再出現を別の状態として扱った。経路、オフセット、時計の有効性にはそれぞれ時間軸があった。

大きな補正は測定を一時停止させた

RFC 891は物理時計、見掛けの時計、実際に提示する時計を区別した。小さなずれはCLK.DELTAの一部を少しずつ移し、推奨値では補正速度をおよそ毎秒2ミリ秒未満に抑えた。

大きなずれでは見掛けの時計を跳躍させることがあった。その後は保持期間に入り、時刻測定用タイムスタンプを無効とした。連続していないローカル時刻を、通常の往復サンプルとして扱わないためである。

見掛けの時計はUTの午前0時に巡回したため、親から少なくとも一日一度、有効な日付と時刻を受け取る必要もあった。親への経路が存在するだけでは日付の鮮度を証明できない。

RFC 778はそれ以前に、ICMPとGGPの三つのタイムスタンプを使うDCNET時計サービスを記述していた。RFC 891は測定を継続的なホスト状態と経路選択へ組み込んだ。

NTPへの影響は明記されたが、同一の仕組みではない

RFC 1059はFuzzballの方式を「Hellospeak」と呼び、時刻同期を経路制御へ取り込んだことがNTPへ強い影響を与えたと記した。同時に、ローカル環境を越える用途には適さないとも述べた。

RFC 958の初期NTPはUDP、階層、メッセージ表現を定めたが、同期・フィルタリングのアルゴリズム、ピア発見、認証は規定しなかった。RFC 1305では複数サーバーのフィルタリングと選択、誤差境界、Fuzzball由来の論理時計が専用の時刻サービスとして整備された。

影響関係は史料に書かれている。しかしHellospeakをNTPそのものと呼ぶ根拠はない。引き継がれたのは、測定を再利用しながら経路・選択・補正を分ける課題だった。

出典と限界

本稿はRFC 778、RFC 891、RFC 958、RFC 1059、RFC 1305、RFC 2453、IANA登録を用いた。現在のDCN配備、全Fuzzballで同じ定数が使われたこと、親時計の認証、遅延の対称性、RIPへの直接系譜、最小往復遅延が最小の時計誤差になることは示していない。