要約

  • RFC 8570 は、IS-IS のトラフィックエンジニアリングで配布する遅延の測定が負荷によって大きく変動せず、待ち行列の遅延を含めないことを勧告している。
  • 経路選択の基準が安定していても、通常の業務パケットが待たされていないとは限らない。測定対象と用途を分けて説明する必要がある。
  • 静的な値から動的測定への移行は、同じ欄に自動で数字を入れるだけの変更ではない場合がある。履歴の比較可能性と、その値を利用する部門への説明も移行の一部になる。

自動化できた後に残る問い

手で設定していた遅延の参考値を、測定から得られる値に置き換える。運用改善として分かりやすい変更だ。入力作業が減り、更新も自動になる。しかし、この説明だけでは、以前と同じ対象を測るようになったのか、それとも欄の意味まで変わったのかが分からない。

単位が同じなら比較できると思いたくなる。ところが、ある値がどのような条件を表すかは、単位だけでは決まらない。負荷の影響を避けた基準、特定の処理を受ける試験パケットの観測、通常の業務パケットが経験する待ち時間は、いずれも時間で表せても同じものではない。

本稿は、実際の移行で問題が起きたという報告ではない。公開標準が明示する区別から、こうした変更を何として承認すべきかを考える。自動化そのものが悪いのではない。数字をつくる方法が変わると、その数字に依存する判断も点検が必要になるということだ。

待ち時間を避ける測定

2019 年 3 月に発行された RFC 8570 は、IS-IS を使ってリンクの性能情報を配布する拡張を定義する。冒頭では、遅延測定が提供されるトラフィック負荷によって大きく変動せず、待ち行列の遅延を含めないことを勧告している。これは利用者の待ち時間が重要でないという意味ではない。

複数のリンクからなる経路を一つの転送隣接として扱う場合には、待ち行列の影響が小さいトラフィッククラスで測る方法や、構成リンクの測定を合算する方法が例示されている。すべての実装が一つの方式を採用しなければならないという規定ではない。具体的な測定手法も、受信側がその情報をどう使うかも、同文書の範囲外である。

この区別は意図的だ。現在その経路に載っているトラフィックの揺れに左右されにくい参考をつくれば、経路の比較を毎回の混雑変動に直結させずに済む。その用途に合う値が、同時にあらゆるサービスの現在の体験を表す必要はない。

問題は、後から別の用途を黙って付け加えるときに生じる。経路選択用の基準が低く安定していることを、そのまま顧客の通信が待たされていない根拠にしてよいか。測定が意図的に除いたものを知れば、その飛躍はできない。

試験パケットの待遇を聞く

OSPF 向けの RFC 7471 も、負荷によって大きく変動しない遅延測定を目指す。同様の例が示しているのは、試験パケットが受ける扱いも測定の一部だということである。

測定点が適切な位置にあるだけでは、業務を代表しているとは言えない。待ち時間を抑える処理を受けるパケットは、安定した参考を取り出す目的には役立つ。一方、違う処理を受ける顧客のパケットについて、同じ待ち時間を経験したと推定することはできない。

二つの観測のどちらかを偽物と呼ぶ必要はない。何を知るために用いるかを決めればよい。経路の選択に必要な参考と、サービスの問題を見つける観測は両立する。両立に必要な費用を節約するつもりで一つの欄にすべてを背負わせると、節約したのが装置なのか説明なのか分からなくなる。

反応は次の測定条件も変えうる

仮に、ある制御方式がその時点で空いている経路へトラフィックを移すとする。移動によって、その経路の負荷は変わる。そこで発生した新たな待ち時間を直ちに次の移動理由にすれば、観測対象の一部は直前の制御判断によってつくられたものになる。

これは設計上の仮定であり、特定のネットワークで振動が起きた証拠ではない。結果は制御規則、移動量、代替経路、時間関係などに依存する。RFC 8570 がこの制御方式を要求しているわけでも、待ち行列を除けば安定性が保証されるわけでもない。「もっと速く反応する」という要求だけでは仕様が完結しないことを示す例だ。

経路が変わらなくても、情報を配る作業は存在する。観測側の更新を細かくすると、別の装置が処理する情報も増えうる。測定器の性能向上だけを見て、ネットワーク全体の改善とみなすことはできない。

そのため、更新頻度は単純に高ければよい指標ではない。何の変化を早く知れるのか、その情報がどの判断を改善するのか、受信側がどの負担を引き受けるのか。この三つをまとめて考える必要がある。

受け取った値には、それ以前の時間がある

RFC 8570 は、測定と広告の間隔、平均や代表的なフィルター、しきい値、小さな変化の抑制、広告の頻度制限などを設定可能にする。推奨される既定値には、30 秒の測定間隔と、120 秒の広告頻度制限用タイマーがある。移行中や動的測定ができない場合の静的な設定も想定される。これらは実際の装置設定を示すものでも、サービスの応答時間を保証する数字でもない。

受信した値には複数の時点が関わる。最初の観測、区間やフィルターによる値の形成、そして広告の送信である。受信時刻だけが新しくても、元の観測が何を含むかは分からない。

履歴にも同じ違いが出る。ある部門は逐次観測を保存し、別の部門は実際に届いた広告を保存しているかもしれない。後者が静かなのは、再広告の条件を満たす変化がなかったためかもしれず、前者の期間に何も起きなかったことにはならない。

その違いをなくすため、直ちに抑制を解除するのは早計だ。そもそも広告の履歴を唯一のサービス観測記録として扱ってよいのかを先に問うべきである。更新を増やしても、測定対象が違うという問題は残る。

サービス側の観測にも仕様が要る

対照として参考になるのが、IPPM の片方向遅延を定義する RFC 7679 だ。特定のパケットについて、最初のビットが送信されてから最後のビットが受信されるまでを観測する。試験パケットの種類と扱いを正確に報告する必要があり、プロトコル、サイズ、ポート、特別な処理などによって結果が変わりうる。校正や、長い遅延と損失を区別する基準、分かる範囲の経路情報も解釈に関わる。

この方式を RFC 8570 の必須実装にするという話ではない。サービスの証拠として使う観測にも、それが何を代表するかの説明が必要だということだ。別部門が持つ二台目の測定器であっても、同じ低待ち時間の扱いを受ける試験パケットを使っていれば、通常の業務の待ち時間を独立に見ているとは限らない。

結果を比較する際には、方向、流量の扱い、観測区間、測定方法の変更を先に確かめる。条件の違う二つの数字を引き算して、その差を待ち行列と呼ぶことはできない。

RFC 7679 は最小値を軽い負荷での伝搬・伝送条件の手掛かりとし、それより高い値を混雑の兆候となりうるものとして説明する。その読み方は、条件が理解された測定の中で意味を持つ。数字が同じ単位だというだけでは、その前提を満たさない。

静的な値を卒業する前に

手動の参考値には用途がありうる。測定を導入するまでの移行や、動的な測定が利用できない状況では、明示的に承認された静的設定が合理的な場合もある。手入力であることだけを不正確さや不誠実さと結びつけるべきではない。

むしろ確認すべきなのは、その値を使う側の理解だ。手動設定を用いた経路評価を承認するなら、承認者はその前提を知っている必要がある。後で動的測定に替えるなら、同じ名前の欄に異なる由来の値が並ぶことを説明する必要がある。

曲線が改善したように見えても、ネットワーク自体が改善したとは限らない。測定方法や試験パケットの処理が変わった可能性がある。逆に曲線の悪化も、実際のサービス悪化だけで説明できるとは限らない。新旧比較を使って判断する部門は、切り替えの時点と意味を知る必要がある。

本稿が確認したのは公開仕様であり、機器の設定、利用者の通信、経路変更、サービスの成否を試験したわけではない。そこから導ける経営上の論点は限定的だが明確である。経路選択に使う性能と、顧客に約束する性能をつなぐ説明には、担当者が必要だ。どちらか一方の仕事が完成しても、もう一方が自動で完成することはない。