要約

  • RFC 9971 は負荷、時間、損失目標、境界を明記したデータプレーン試行を扱うもので、普遍的な性能判定を定めるものではない。
  • トラフィックプロファイル、検索目標、手順の差異、完全な報告がなければ、一つの数値は SLA、アプリケーション性能、導入済み能力の証拠にならない。

数値には試行の輪郭が残る

Maciek Konstantynowicz と Vratko Polak による RFC 9971、Multiple Loss Ratio Search は、ソフトウェア型ネットワークの試験で起きる問題を正面から扱う。二分探索は長くなり得る。試行結果にはノイズがある。連続する試行が食い違えば、ゼロ損失のスループットも一意に読めない。MLRsearch は複数の損失率目標を扱い、結果を理解するための条件を Test Report に残す。

これは測定の規律を強くする。しかし、装置やサービスに時間を超えて固定された「本来の性能」を発見したという意味ではない。結果は、被試験システム、構成、トラフィックプロファイル、試行入力、選択した目標に属する。運用サービスについて語るには、実負荷、経路、保守、復旧を示す別の証拠が必要になる。

測る人、選ぶ人、報告する人

RFC 9971 は Measurer、Controller、Manager を分ける。Measurer は試行を実施し、Controller は負荷と時間を選び、Manager は関係する要素を準備して Test Report を作る。試行の出力には損失率、有効時間、転送レートが含まれ、試行結果はその出力と入力を組にする。

この定義を越えて数字を借用してはならない。試行転送レートはアプリケーションの goodput ではない。低い損失率も、低遅延、正しい経路、障害からの回復、利用者の可用性、契約上の達成を自動的には示さない。それぞれ別の制御面と、別の観測記録を必要とする主張である。

複数目標は設定上の判断を表に出す

MLRsearch には複数の Search Goal を置ける。Goal Final Trial Duration、Goal Duration Sum、Goal Exceed Ratio、Goal Width は、どれだけ測るか、高損失の試行時間をどの程度許容するか、関連する上下限をどこまで近づけるかを左右する。

RFC 9971 は全用途に通用する設定を選ばない。目標パラメータは試験手順の運用者が決め、Controller の負荷選択ヒューリスティックは実装固有である。したがって、二つのラボが「MLRsearch」と書いただけで比較可能になるわけではない。トラフィック、目標、時間、境界、分類方法を示して初めて比較の土台ができる。

ばらつきは消すべき汚れではない

同じ負荷でも損失率が異なる場合があり、より大きい負荷がより低い損失率を返す場合もあると RFC は認める。関連する上下限はその反転を保守的に扱うための仕組みであって、観測された変動を保証へ書き換える機能ではない。

予熱、反復、RFC 2544 の試行手順からの逸脱も報告に残す必要がある。RFC 9971 は逸脱を許すが明示的な記録を要求し、比較可能性が弱まると注意する。短く再現しやすい試験は有用でも、それだけで RFC 2544 準拠のスループット結果になるわけではない。

使えるのは測定の受領書

有用な報告には、SUT と構成、トラフィックプロファイル、提供負荷の定義、完全な Search Goal、関連上下限、逸脱を含める。運用サービスの評価は、その上に独立した本番テレメトリ、経路差、遅延、保守、復旧、契約メトリクスを重ねる。ラボ試験と本番観測は、互いの代用品ではない。

Konstantynowicz の貢献は、ラボの測定を点検可能にすることにある。測定していない運用システムの保証を代弁させることではない。

情報源