RFC 3116：ATM遅延値に含まれる時計の証拠

要約

RFC 3116は送信と受信のtimestampを対応づけ、共通の100 MHz以上・10 ns resolutionのclock信号を使い、bit長、accuracy、rollover値を記録するよう求めた。
結果はVCC数、bearer class、rate、burst、integration periodに依存した。graphは制御されたtrialの記録であり、productionやapplicationの保証ではない。

引き算の前に証明すること

RFC 2761はCell Transfer Delayを、measurement point 1でcellが出た時点から、対応するcellがmeasurement point 2へ入った時点までと定義した。RFC 3116は、その短い定義を実行可能なtestへ変えた。

2001年6月のInformational RFCであるこの文書は、ATMそのものを標準化したのではない。vendorや利用者が比較可能なperformance dataを得るための方法を定めた。送受信器には同じclock信号を与え、少なくとも100 MHz、すなわち10 nsのresolutionを持たせる。test cellの送信timestampは受信時の観測と相関できなければならない。

有限bitのcounterは最大値の次にゼロへ戻る。送信がrollover前、受信が後なら、epochを知らない引き算は負の遅延や巨大な値を作る。そのため最大timestamp値を記録し、test cellの説明にtimestamp length、rollover value、nanosecond単位のaccuracyを含める。推奨されたO.191 cell以外を使う場合も、その形式を開示する。

装置のperformance claimは、cellがSUTへ入る前から始まっていた。clock source、capture point、counter epoch、送受信eventのmatchingがそろって初めて、差を装置に帰属できる。switchはstopwatchを所有していない。

共通clockでも全ては確定しない

共通frequency referenceは相対driftを減らすが、phase、配線、校正、event captureの位置を自動的には証明しない。送信timestampが物理的なexitより前、受信timestampがentryより後に付くこともある。二つのcounterは精密にずれたまま動ける。

同時期のRFC 2679はIP one-way delayについて、synchronization、accuracy、resolution、skewを分け、host timeとwire timeも区別した。RFC 2330はIPPMのframeworkを与え、RFC 7679は後にRFC 2679を置き換えたが、timestampを自己証明する事実にはしなかった。

IP path measurementとATM device benchmarkは同じものではない。ここで重要なのは、別のIETF measurement communityもinstrument uncertaintyをmetricの外へ追い出さなかったことだ。

100 MHzという入力条件を、end-to-end accuracyが10 nsだと読み替えてはいけない。capture circuit、clock phase、wire delay、event definitionは別々のreceiptである。

Queueとloadも数値を書いた

信頼できるclockがあっても、delayはloadから独立しない。ATM switchは複数のvirtual circuitをmultiplexし、bearer classをscheduleし、burstをbufferする。RFC 2761のCell Delay Variationもtraffic load、orientation、distribution、integration periodを条件にしていた。

RFC 3116は1 VCC、12 VCC、最大VCCでtestを分け、steady、bursty UBR、VBR、mixed loadを区別した。packet size、packet rate、bearer class、VPI/VCI、PCR、SCR、MBSを結果に添える。throughput testでないCTD testはline rateの90%を超えないようにする。

測定前にはpacket countを比較してconnectivityとloadを確認し、合わなければrateを下げる。これは都合のよい結果を作る操作ではない。lossやoverloadが起きているtrialをdelayだけのtestとして扱わないための境界だった。

text、graph、histogramにも別の役割がある。averageはlong tailを隠し、maximumは頻度を隠す。RFC 3393とRFC 5481が後に示したように、同じ秒という単位でもdelay variationの定義が違えば意味は一致しない。

Trialは準備と回復を含んだ

必要ならPNNI routing updateを送り、settleを待つ。RFC 2225に従うATMARPでdestination addressを解決する。その後でloadをかけ、残留packetを待ち、次のtrial前にSUTをrestabilizeさせる。

address resolutionの成功はtrial開始の条件であり、delay resultではない。routing waitはtransientを減らすが、全control stateの完成証明ではない。late packetを別trialから隔離することも、そのpacketのservice成功を意味しない。

刺激時間は最低60秒、高varianceなら最低300秒が推奨された。長い時間は真実を保証しない。短い窓が安定性を過大評価する危険を減らすだけである。

RFC 1242とRFC 2544が作ったBMWGの分業では、terminologyが測る対象を、methodologyがprocedureを定めた。RFC 2761とRFC 3116の関係も同じで、metric名だけでは比較可能性を生まない。

Aggregateは原因を指さない

複数装置を一つのsystem under testとしてend-to-end benchmarkを取ることもできた。しかしRFC 3116は、aggregateが装置間のasymmetryや中間装置のlatencyを隠すと警告した。

correlated timestamp pairは宣言したboundaryのelapsed timeを示す。内部queue、scheduler、故障部品まで特定しない。原因を分けるには追加measurement pointが要る。productionを語るなら現実のpath、configuration、loadも必要だ。

このRFCにvendor rankingや実測値はない。methodologyを勝敗表に変えるのは、sourceにない歴史を作ることになる。

数値にはcustodyがあった

generatorがstimulusを決め、clockがreferenceを与え、capture hardwareがeventを刻み、counterがepochを保持する。SUTは特定条件でforwardし、reporterがrolloverを復元して集計し、readerがcommon denominatorを判断する。

一つでも消えると、formatが正しい数値だけが残る。10 ns tickは10 ns accuracyではない。histogramはSLAではない。cell delayはapplication latencyではない。RFCがあることはvendorが従った証拠ではない。

RFC 3116の成果は、graphに測定履歴を背負わせたことにある。縦軸の点はclock、counter、trafficから切り離せなかった。

遅延の数値は時計についての主張でもあった――RFC 3116

なぜ重要か

要約

引き算の前に証明すること

共通clockでも全ては確定しない

Queueとloadも数値を書いた

Trialは準備と回復を含んだ

Aggregateは原因を指さない

数値にはcustodyがあった

情報源

プロフィールの詳細

Strategic Circle

Leadership Alliance

Strategic Circle 向けブリーフィング

Leadership Alliance 解説