要約

  • RFC 9693では、Phase 1が限定されたNAT接続を生成し、Responderが変換後の4-tupleを保存する。その既知の状態に対してのみ、Phase 2でスループット、損失、遅延を測る。
  • Phase 2の無損失は、宣言された条件下の一つのブラックボックス実験を示すだけで、内部表、インターネット実トラフィック、TCP、運用余力、利用者の処理完了までは証明しない。

戻り道には事前の接続が要る

Initiatorからserver側へ新しい4-tupleを送ると、DUTは接続追跡エントリを作り、変換して転送できる。一方、Responderが逆方向から未知のtupleを作っても、有効な接続に属さないパケットは捨てられる。ここにステートフル試験の非対称性がある。

RFC 9693の構成には二つの表がある。DUT内部のconnection tracking tableはTesterから見えず、容量、置換方針、内容も不明である。Responderのstate tableは、実際に到着した変換後4-tupleだけを保存する。送信したtuple数、正方向で受信したフレーム数、保存した変換後tuple数、逆方向で検証できた接続数は、それぞれ別の受領記録である。

「100万セッション」という一語では、この差が消える。提供しただけなのか、正方向で通ったのか、内部に残ったと仮定したのか、逆方向でも有効だったのか。RFC 9693はその間を分解する。

擬似乱数は状態空間を数十億に広げる

RFC 4814は、都合のよいハッシュ配置を避けるため、送信元・宛先ポートに一様な擬似乱数を推奨する。ステートレスな転送では分布を広げるが、ステートフルNATでは未知の4-tupleごとに新しい状態生成を要求し得る。

一つのIPアドレス対でも、同RFCの広いポート範囲は3,170,829,312通りになる。IPアドレス範囲を加えれば、可能なフロー数は四つの範囲の積で増える。無制限の「ランダム化」は現実性ではなく、意図しない表枯渇を作り得る。

そこでRFC 9693は乱数性を維持しながら範囲を制限する。送信元ポートは数万程度と広く、宛先ポートは利用目的に応じて数十から数千程度と小さくできる。クライアントの一時ポートと人気サービスの宛先ポートが対称でないからだ。範囲そのものが結果の一部であり、「ランダムトラフィック」だけでは再現条件にならない。

Phase 1がPhase 2の母集団を作る

Phase 1ではInitiatorだけが送信する。DUTが変換と接続生成を行い、Responderは受信した変換後tupleを記録するが送信しない。こうして見えないDUT表と見えるResponder表に対応する状態を準備する。

Phase 2のスループット、遅延、フレーム損失、PDVを行う前には必ずPhase 1が必要である。しかも準備レートは最大接続確立レートより十分低くなければならない。そのため、接続確立レートを先に測り、preconditioningが負荷試験にならない値を選ぶ。

方法は二つの極端な条件を区別する。接続確立レートを測る場合、各フレームが異なるtupleを使い、UDP timeoutをPhase 1より長くして、新規作成だけが続くようにする。既存状態で転送性能を測る場合、Phase 1で対象tupleをすべて列挙し、timeoutをPhase 1、間隔、Phase 2の合計より長くして、測定中に新規作成も削除も起こさないようにする。

これは日常トラフィックの模型ではない。状態生成コストと既存状態上の転送コストを分離するための実験条件である。

正方向の到達だけでは保存を確認できない

ブラックボックス試験はDUT表を直接読めない。Phase 1のフレームがすべてResponderに届いても、各接続が残っているとは限らない。生成レートが高すぎた、上限に達した、置換された、またはgarbage collectionが走った可能性がある。

検証ではResponderが保存したすべてのtupleを使い、安全係数を掛けた低いレートで逆方向に一つずつ送る。全部がInitiatorに届いたとき、対象接続が存在し、正逆両方のレートが妥当だったという限定的な証拠になる。

逆方向の欠落にも複数原因がある。Phase 1のRが高すぎる、検証のrが高すぎる、容量が尽きた、LRUで古い状態が置換された、満杯時に複数状態が一括削除された、という場合を一つの観測だけでは区別できない。「欠落＝容量不足」と即断してはならない。

容量は探索区間として測る

capacity測定は、安全に格納できるC0と、その数で検証済みの確立レートR0から始まる。接続数を倍増させ、DUTがcollapseするか、確立レートが大きく低下するまで指数探索する。その後、明示した誤差Eまで二分探索で区間を狭める。

内部方針で観測は変わる。新規状態を拒否すれば最初の接続が残り、LRUなら後の接続が残る。複数LRUを一括削除する実装では、検証成功数が物理容量より少なくなることもある。小数点のない整数であっても、必ずしも内部表の直接読取値ではない。

tear-downにも独立した測定がある。N個の接続を装填し、実装固有の帯域外操作で削除する時間を測り、Nをその時間で割る。全表消去と一件ずつの削除は同じ処理とは限らない。

順序、時間、CPUを隠してはならない

Responderのstate tableには書込・読出順序がある。round robin書込はエントリを新鮮に保ち、擬似乱数読出はRFC 4814の方針に従う。計算量を抑えるround robin読出も選べる。昇順・降順は別実験として利用でき、ハッシュ、cache、置換方針の影響を示す可能性がある。

timeout、二つのphaseの長さ、その間隔は状態の生存を決める。active CPU core、affinity、hashsize、nf_conntrack_max、hardware、NIC、OS、kernel、実装versionも性能を変える。RFCは繰り返し実験を要求し、中央値、1 percentile、99 percentile、試行回数、二分探索誤差の報告を推奨する。

UDPの数字をサービス結果へ昇格させない

UDPが使われるのは、任意の一定フレームレートを作りやすく、TCPの輻輳・flow controlや3-way handshakeを混ぜずに済むからである。しかし実装はUDPとTCPでtimeoutや処理経路を変え得る。RFC 9693自身が、UDP結果だけではインターネット転送を十分に表さないと警告し、HTTP/HTTPSにはRFC 9411を参照する。

したがって無損失のPhase 2が証明するのは、特定のDUT、build、設定、tuple母集団、順序、timeout、方向、レート、CPU配分で、限定されたworkloadを処理したことまでである。内部表の真の構造、実トラフィック、TCP、運用余力、利用者が見た継続性は別に観測しなければならない。

共通仕様は比較の文法を与える。running codeが観測を与える。両者の間の記録を残して初めて、スコアは意思決定に使える。

出典