要約

  • RFC 2030の通常のSNTPクライアントは、原則として一台のサーバーを使う。四つのタイムスタンプから遅延とオフセットを推定できても、完全なNTPが持つ複数源の比較や故障源の排除は得られない。
  • そのためSNTPは同期サブネットの端に置かれる。クライアントは依存先を持たない葉、サーバーは信頼できる基準時計に直結した根であるべきだ。中間に置けば、一つの判断が下流の共通時刻になる。
  • RFC 2030のanycastでは、クライアントは最初の応答者に結びつき、その後unicastを続ける。先着は一地点での一回の順序であって、最短、最良、真正、安定、同一個体を意味しない。

時計が一秒ずれているかを調べる前に、誰のずれが何台へ伝わるのかを調べなければならない。RFC 2030は、その順番を設計に埋め込んでいた。

1996年10月に公開された同文書は、NTPのメッセージ形式を維持しつつ、完全なNTPが複数の時刻源を選別し、誤った源に耐えるために用いる状態やアルゴリズムを大幅に省いた。小型機器には有益だったが、省略された判断は消滅したのではない。配置と運用へ移った。

簡略化には置き場所があった

RFC 2030はSNTPを同期サブネットの「extremities」に限るよう強く勧告する。クライアントは最大stratumの葉で動き、ほかのNTP/SNTPクライアントがそのクライアントへ依存してはならない。単一源が誤っても、葉なら影響はそこで終わる。中継役にすれば、比較していない時刻が依存木を下る。

根側の条件も狭い。SNTPサーバーをstratum 1で使えるのは、信頼できるradioまたはmodemの時刻源へ直接つながり、ほかの源がない場合である。RFC自身が、信頼できる主サーバーは通常、冗長な参照源、異なるネットワーク経路、用途に合わせたアルゴリズムを必要とすると述べる。利用者が多いことと、根拠が多いことは別である。

四つの時刻は一回の往復を囲む

T1はクライアント送信、T2はサーバー受信、T3はサーバー送信、T4はクライアント受信である。往復遅延は d = (T4-T1) - (T3-T2)、オフセットは t = ((T2-T1) + (T3-T4))/2 と推定する。RFC本文の遅延式には符号の誤植があり、Verified Errata 517がここで用いた式へ訂正している。

応答のoriginate timestampは要求のtransmit timestampと一致すべきである。これは一つの要求と一つの応答を結ぶ検査になる。しかし経路の対称性、参照時計の正確さ、アドレスを運用する主体、次回も同じプロセスへ届くことは証明しない。

LI=3は未同期を示し、ほかの値にかかわらず破棄すべき最重要の警告である。stratum、非ゼロのtransmit、originateの一致も拒否材料になる。ただし、悪い条件がないことは健康証明ではない。reference identifierやreference timestampはサーバー側の申告である。

statelessは記憶の移転である

SNTP要求は、最初のoctetとtransmit timestamp以外をほぼゼロにできた。サーバーはクライアントごとの永続状態なしで返答でき、RFCは単純なstateless RPCになぞらえた。

共通部分を小さくする優れた設計だが、運用の記憶は別に必要だ。なぜそのサーバーを選んだか、名前がどのアドレスになったか、経路や応答者がいつ変わったか、独立した比較源があったかを記録しなければならない。

Lu Hengの「minimum initial specification」は、この責任分担を明確にする。共通層は形式とローカルに検証可能な規則へ絞る。情報源の多様性やfailoverは運用者の選択面に残る。「running-code primacy」は、文書の公開、実装、設定、実際の採用を同じ現実として扱わない。

先着応答は理由を持たない勝者だった

RFC 2030のanycastクライアントはbroadcastまたはmulticast groupへ要求し、複数サーバーが個別のunicast addressから返答できた。クライアントは最初の一通へbindし、その後は通常のunicastを続ける。

この方法は速く決められるが、なぜ勝ったかはほとんど残さない。routing、queue、負荷、競合パケットの損失、multicast scope、瞬間的なjitterのどれでも順序は変わる。「今回ここで最初」は、地理的な近さ、恒常的な低遅延、時刻の正しさを意味しない。

RFC 1546が扱う一般的なanycast史とは領域を分ける。RFC 2030固有の論点は、探索時の先着を一時的なunicast関係へ変換した点にある。またmulticast/anycast向け認証拡張は将来別文書で公開するとされ、設計はprovisionalだった。未完成の拡張を、当時すでに存在した本人性保証として読んではならない。

葉という配置は証拠の配置だった

構文上正しいパケット、計算できる交換、正しくdisciplineされた時計、正しい順序の業務記録は、異なる現実層に属する。一段が正しくても次段は失敗しうる。

下流へ時刻を供給し、単一源故障へ耐え、持続する情報源の同一性を主張するなら、SNTPの葉を「サーバー」と呼び替えるだけでは足りない。独立源、経路多様性、参照元の来歴、継続観測、不一致時の手順が必要になる。

RFC 2030が読みやすくしたのは一回の交換である。一通の応答を合意へ変えたのではない。

出典