RFC 3133：良好な配送率が悪い利用体験を隠すとき

要約

RFC 3133 は、一つの Frame Relay 仮想接続の一方向について、payload octet と frame の配送率を定義し、CIR 内の負荷と超過負荷を分けた。
小さな確認フレームが一つ失われるだけで、多数のデータフレームが再送され得る。比率は測定範囲内で正しくても、アプリケーションの良好な結果までは証明しない。

百分率が見落とした一枚

データ転送の大半が正常に終わった直後を考える。大きなデータフレームは一方向に届いた。反対方向へ返る短い確認だけが途中で捨てられた。受信済みの octet を数えれば欠落はごく小さい。frame を数えても、失敗は多数のうちの一つにすぎない。

しかし送信側から見れば、その一枚は進捗を確定する証拠だった。証拠が戻らなければ、timer を待ち、すでに届いたデータまで再送することがある。ネットワークの分数は高いままなのに、完了時間と利用者の体感は悪化する。

RFC 3133 はこの例を Data Delivery Ratio（DDR）と Frame Delivery Ratio の議論に置いた。配送率は特定のアプリケーションにとっての配送効果を代表しない場合がある、と自ら注意したのである。

ここで誤っているのは計算ではない。計算は、宣言された境界を通過した対象の割合を答えている。誤りは、その答えを別の問い――アプリケーションは必要な制御証拠を受け取り、仕事を完了したか――へ無断で拡張するときに生じる。

回線速度と約束された速度

RFC 3133 は、まず「速さ」に見える複数の概念を切り分けた。Access Channel は利用者が Frame Relay 網へデータを投入する物理的な経路であり、Access Rate は投入できる最大速度を示す。だが、物理回線の速度すべてをサービスが保証するとは限らない。

Committed Information Rate（CIR）は、データが提示されたときにサービス地点間で維持される約束上の転送速度である。Bc は測定区間 Tc に通常条件で転送すると合意した bit 数、Be は Bc を超えて網が配送を試みる未保証の burst だった。

Tc は一定周期で開閉する箱ではない。RFC は、入力データによって始まる sliding window であり、Bc/CIR から求めると説明した。したがって committed か excess かを判断するには、port の速度だけでなく、契約値と到着時系列が要る。

Discard Eligible（DE）bit も、廃棄済みという印ではなかった。混雑時に低い優先度で捨てられ得ることを示す。RFC 3133 は discardable と discarded を別の用語として扱う。DE が立っていても混雑が解消すれば届く。DE がなくても PVC 単位や上位層の規則で廃棄候補になり得る。形式や FCS が壊れた frame は、混雑とは違う理由で拒否される。

契約、分類、廃棄資格、実際の廃棄は別々の出来事だった。一つの loss counter だけでは、誰が何を決めたかは復元できない。

一方向、一つの仮想接続

この文書は RFC 1242 の定義形式を引き継ぎ、terminology 文書と methodology 文書の役割も分けた。前者は benchmark と関連語を定義し、後者は取得手順を定める。式が載ったことは、実際の試験が済んだことを意味しない。

DDR は、試行した payload octet に対して正常に届いた payload octet の割合を測る。address field と FCS は payload に含めない。Frame Delivery Ratio は、送信を試みた frame に対する正常な受信数を測る。いずれも対象は、一つの virtual connection の一方向である。

full duplex なら方向ごとに独立した比率がある。データが進む方向の高得点は、確認が返る方向の健全性を証明しない。一つの DLCI の値は port 全体を代表しない。二つの観測点間の成功も、その手前と先の処理を含まない。

さらに、RFC は committed と excess を分けて報告できるようにした。DDR_c は CIR 内、DDR_e は超過分である。合算値が正しくても、保証対象だけが悪化している事実を平均が隠す可能性がある。

比率には住所が必要だった。virtual connection、方向、区間、負荷区分、frame 長、header、入口と出口を明記して初めて、その数字が何を主張できるかが定まる。

制御価値は byte 数では量れない

octet を単位にすれば大きいデータフレームの重みが増し、小さな確認の重みは下がる。frame を単位にすれば両方を一枚として数える。どちらも、その確認が protocol state に与える権限を保存しない。

確認は送信 window を進め、累積的な到達を認め、timer の満了を避け、再送待ちの state を解放することがある。機能上の価値は長さではなく、それによって許される state transition にある。

例えば千枚のうち一枚だけ失えば 99.9% になる、と説明することはできる。だが RFC 3133 はその数値の試験を報告していない。記事が架空の算術を実測値に変えてはならない。文書が示したのは、一つの小さな確認損失が多数のデータ再送につながり得るという因果の可能性である。

逆に、確認損失が必ず大きな損害になるわけでもない。後続の累積確認が補い、window や timer、実装の挙動が影響を抑えることもある。この例が否定したのは「高い配送率ならアプリケーションも良好」という推論であって、別の絶対法則ではない。

平均遅延に入れなかった frame

Frame Transfer Delay にも母集団の境界がある。RFC は、測定点から出る frame exit event と、次の測定点へ入る frame entry event を定義した。平均値の対象は受信された frame であり、区間中に送られたものの届かなかった frame は計算から外れる。

定義としては整合している。だからこそ、delay は loss と組み合わせて読まなければならない。生き残った frame だけが速ければ平均は良好になり、最悪の結果を持つ欠落分は数字から姿を消す。

Frame Transfer Delay Variation は観測した最大と最小の差だった。RFC は大きな変動が TCP の round-trip time 計算と throughput に影響し得ること、過大な遅延が Voice over IP のようなアプリケーションを害し得ることを述べた。これは仕組みの説明であり、特定網の測定結果ではない。

廃棄が保護になる場合

RFC 3133 は error frame の理由を列挙した。長すぎる、短すぎる、bit 長が不正、DLCI が無効、abort sequence がある、flag delimiter が不正、FCS に失敗する、といった場合である。壊れた frame を止めることは、上位層へ誤データを渡すより適切であり得る。

したがって discard の増加を一律に「悪化」と呼べない。契約外 traffic を policing したのか、混雑時の優先度で選んだのか、integrity check で拒否したのかによって意味が変わる。上位層で再送が起きても、その事実だけから原因は特定できない。

監査では経路を残す必要がある。入口で frame を観測したか。committed と excess のどちらか。DE はどうだったか。何の規則で候補になったか。実際の廃棄理由は何か。逆方向の確認はどこまで届いたか。transport は何を再送し、application は完了したか。最終比率だけを保存すれば、この因果列は失われる。

用語集であって、製品の成績表ではない

RFC 3133 は 2001 年 6 月、IETF Benchmarking Methodology Working Group の Informational 文書として公開された。RFC 1242、RFC 1944、RFC 2285 の用語を拡張し、Frame Relay Forum と Frame Relay service MIB の概念も取り込んだ。

特定の装置を試験した文書ではない。事業者がすべての counter を実装したこと、SLA が式を正しく使ったこと、利用者が一定の性能を得たことも示さない。最終 Internet-Draft は文書の編集過程を示すが、deployment の証拠ではない。

RFC 1944、RFC 2544、RFC 2889 は隣接する methodology、RFC 2761 は ATM benchmarking、RFC 2954 は Frame Relay service の managed object、後年の RFC 6349 は TCP throughput test の framework を扱う。それぞれ文脈を与えるが、RFC 3133 が現場で実施されたという証明にはならない。

残った価値は、指標の内側に指標の限界を書いたことだ。network layer が自分の尺度で成功しても、その上に依存する application が別の尺度で失敗し得る。

三つの台帳に分ける

第一の台帳は network の観測を持つ。Access Channel、DLCI、方向、区間、CIR、Bc、Be、Tc、offered/delivered の octet と frame、committed/excess の内訳、DE、policing、FECN/BECN、error と discard reason、観測点を残す。

第二は transport の履歴である。失われた確認、sequence state、送受信時刻、timer、再送の trigger、再送した frame と byte、回復終了を記録する。第三は application の台帳であり、operation ID、完了条件、時間予算、retry、最終状態、利用者への結果を持つ。

上位の空欄を下位の比率で埋めてはならない。DDR は定義した payload octet の比率を証明する。frame ratio は frame の比率を証明する。完了、契約充足、人の満足を証明する receipt ではない。

Frame Relay が主役でなくなった後も、問題は残った。組織は集約しやすい signal を健康指標に選び、やがてそれが単なる projection だったことを忘れる。RFC 3133 が示す対処は、数字を捨てることではない。数字の管轄を保存し、system 全体を語る前に別の層から別の証拠を取ることである。

小さな確認フレームは、byte 数と結果の大きさが比例しないことを教えた。そして信頼できる測定とは、何でも説明する測定ではなく、どこで説明をやめるかを明示した測定だった。

配送率は良好だった。アプリケーションは遅かった――RFC 3133

なぜ重要か

要約

百分率が見落とした一枚

回線速度と約束された速度

一方向、一つの仮想接続

制御価値は byte 数では量れない

平均遅延に入れなかった frame

廃棄が保護になる場合

用語集であって、製品の成績表ではない

三つの台帳に分ける

出典

プロフィールの詳細

Strategic Circle

Leadership Alliance

Strategic Circle 向けブリーフィング

Leadership Alliance 解説