要約

  • RFC 5180 は IPv6-capable device を比較するための laboratory profile を示す。測定値の効力は、frame size、prefix、destination、neighbor mode、方向、header chain、filter、port scale、software build の範囲内に限られる。
  • Hop-by-Hop は通常の throughput test ではない。1%、10%、50% の load と resource telemetry で処理影響を見る。RFC 8200 以後は、node が明示的に処理設定されていたかも profile の一部である。

ある release の回帰試験はすべて green だった。後で分かったのは、試験装置の設定変更により random destination が一つの宛先へ戻り、filter が外れ、multi-port run が single-port run に置き換わっていたことだった。数値は前回と一致した。しかし、一致したのは performance ではなく、より軽い仕事に対する結果だった。

品質保証では、test name より test identity が重要である。RFC 5180 は 2008 年の Informational RFC で、RFC 2544 を IPv6 向けに補完し、RFC 1242 の用語を利用する。repeatability、variance、少数 trial の statistical significance を求める。したがって「RFC 5180 を実行した」という一文は開始点であって、再現記録ではない。

versioned profile が回帰の単位になる

Ethernet の推奨 frame size は 64、128、256、512、1024、1280、1518 byte である。小さい frame は同じ bit rate でも一秒当たりの packet decision を増やす。大きい frame は Gbit/s を高く見せやすい。どちらか一つの合格を全 traffic の合格にすると、試験入力を製品属性へ変換してしまう。

正しい regression object は frame series と期待 workload の関係である。物理条件も固定する。Ethernet の理論 frame rate には clock slop のプラスマイナス 100 ppm があり、Packet over SONET では bit stuffing による変化がある。dashboard の小数桁は、計測系より多くの精度を作れない。

destination も version 管理すべき input である。single source-destination pair は狭い lookup path や cache を温める。random destination は別の負荷を作る。RFC は両方を求め、/48、/64、/126、/128 を代表的な prefix boundary とする。宛先生成 seed、範囲、prefix 数が失われた run は、前回と比較できない。

green の中に方向差を埋めない

RFC 5180 は全 test の bidirectional traffic を勧める一方、bidirectional result が二方向のうち低い方だけを示すと明記する。asymmetric configuration なら unidirectional test を加え、どちら側が制約されたかを分解する。

これは network の実態に合う。ingress と egress の policy は同じとは限らない。request は小さく response は大きい場合がある。片方向だけ深い classification を通ることもある。一つの合否へまとめる前に、二つの path を別々に保存しなければ、改善対象を誤る。

IPv4 と IPv6 の mix も同様である。methodology は IPv4-only、IPv6-only、90/10、50/50、10/90 を並べる。pure IPv6 の合格は、shared lookup、buffer、policy resource を使う mixed environment の合格ではない。production mix が変われば、古い test は自動的に新しい問いへ答えない。

single-port は per-interface performance、multi-port は platform scaling を測る。line card の結果を port 数で掛けても、fabric、memory、software resource の共有制約は測れない。回帰計画は両者を別 profile として持つ必要がある。

Hop-by-Hop は pass/fail の種類が違う

extension header は種類ごとに試験し、さらに複数 header の chain を試す。header 有無を小さい frame で比較するときは共通の最小 frame size を使う。そうしないと、frame 差を parser 差として報告してしまう。

Hop-by-Hop では目的そのものが異なる。RFC 5180 は interface bandwidth の 1%、10%、50% で送信し、device resource を監視する。通常 throughput の最大値ではなく、処理 impact を観察する。CPU や memory は test traffic interface から独立した out-of-band で採る。これによって hardware path、recirculation、software path、control-plane pressure の手掛かりを得る。

ただし 2008 年の前提を現在の仕様へそのまま持ち込んではならない。RFC 5180 は RFC 2460 の処理モデルを説明していた。RFC 8200 は、path 上の node が Hop-by-Hop を examine/process するのは明示的に設定された場合とする。RFC 7045 は high-performance router が無視または slow path へ送る可能性を述べ、RFC 9098 は lookup depth、recirculation、software forwarding、drop の制約を分析する。

現在の QA receipt には、処理設定、option 内容、load、duration、protection policy、resource telemetry が必要である。同じ packet fixture でも設定によって code path が変わる。throughput drop だけではどの path を通ったか確定せず、security resilience も証明しない。

neighbor と filter は fixture である

RFC は static neighbor と dynamic Neighbor Discovery の両方を許す。dynamic を選ぶ場合、tester は cache を active に維持する。endpoint address を DUT の一 hop 先に置き、Neighbor Unreachability Detection による NS/NA storm を避ける。

つまり neighbor table は test 前の雑務ではない。static entry、active refresh、expiration/rebuild は異なる state transition を実行する。production defect が cache change で起きるなら、static test の合格は反証にならない。

filter 数、routing table、control traffic も fixture に含まれる。upper-layer 情報を得るため extension header chain を辿る filter は、より深い parse や別の forwarding stage を要求する。policy のない test は、policy を製品価値として購入する環境を代表しない。

recovery も一つにまとめられない。overload からの system recovery と device/software reset 後の recovery は別 test である。RFC は short-term variance が大きいため IPv6 の back-to-back frame test を推奨しない。測れることと安定した quality signal になることは同じでない。

isolated lab は production の代役ではない

benchmark topology は独立し、test traffic を production や management network に流してはならない。観測は DUT/SUT の外から行う black-box で、benchmark 専用 capability を device に持たせるべきではない。

この isolation は再現性を高める。同時に、production が測られていないことを明確にする。実環境の routing churn、queue interaction、failure domain、policy drift、mixed version、user outcome は意図的に取り除かれている。結果の利用時だけそれらを戻すことはできない。

address space にも境界がある。RFC 本文の prefix には verified technical erratum があり、現在の IANA registry は benchmarking 用を 2001:2::/48 とし、globally reachable を false としている。test address を正しく保つことは、lab evidence の所在を守る。

scope test も必要である。RFC 8219 は translation と encapsulation transition technology を RFC 5180 の外側に置き、state table や overload を含む補完方法を示す。dual stack の評価方法を stateful gateway へ流用してはならない。

release 判定に必要な receipt

各 run に immutable profile ID を付ける。device、build、feature、port、media、topology、tester、clock、frame series、destination seed、prefix、neighbor mode、extension header、filter、route、direction、IP mix、offered load、duration、trial count、loss、latency、sample distribution、out-of-band resource、recovery method、deviation を格納する。

method owner、lab operator、statistics reviewer、release owner、production observer を分離する。release owner は tested build と candidate build の同一性または差分を証明する。production observer は安全な観測で外挿を検証する。green mark は一つの責任範囲を越えて移動しない。

出典

  1. RFC 5180 HTML
  2. RFC 5180 text
  3. RFC Editor 情報ページ
  4. IETF Datatracker document
  5. IETF Datatracker history
  6. IETF Datatracker references
  7. RFC 5180 errata
  8. RFC 2544
  9. RFC 1242
  10. RFC 8200
  11. RFC 7045
  12. RFC 9098
  13. RFC 4861
  14. RFC 8201
  15. RFC 6890
  16. IANA IPv6 Special-Purpose Address Registry
  17. RFC 8219
  18. Heng Lu — reality layer
  19. Heng Lu — minimum specification と voluntary adoption
  20. Heng Lu — running code の優先