要約

  • RFC 7683の OC-Reduction-Percentage = 100 は、反応ノードが本来送るはずだった新規要求のうち、有効な過負荷制御状態に一致する全件への軽減処理を求める。仕様は、絶対的なトラフィック減少を保証しないと明記している。
  • 運用結果を立証するには、OLR、受理されたOCS、要求ごとの処理記録、実測トラフィック、有効スループットを、同じノード、適用範囲、時刻で結ぶ必要がある。

数字が示すのは結果ではなく依頼

「100パーセント削減」は、普通なら処理後の集計値に聞こえる。Diameter Overload Indication Conveyance（DOIC）では順序が逆だ。RFC 7683の OC-Reduction-Percentage は、送信側が何も対策しなければ送るトラフィックを基準に、どの割合を減らしてほしいかを表す。100は、報告ノードが深刻な負荷にあり、新しいメッセージを処理しないため、対象となる全要求に軽減処理を求める値である。

OLRは制御上の意図を強く証明する。しかし、受信側のカウンターではない。すべてのクライアントがDOICを扱えることも、各反応ノードが同じ版の状態を保持したことも、要求がネットワーク全体から消えたことも示さない。命令文を観測結果として引用した瞬間に、確実だったはずの狭い事実まで疑わしくなる。

Ben Campbellの経歴は、この区別を追う手掛かりになる。IETF Datatrackerは、リアルタイム通信の専門家であり、IAB、ART Area Director、複数のワーキンググループ議長を務めた人物として紹介している。Campbellは、過負荷制御の要件を整理したRFC 7068、DOICを定義したRFC 7683、負荷情報と過負荷情報を分けたRFC 8583の著者に名を連ねる。そこでは、各ノードが知る事実と相手に求める行動が混同されていない。

報告ノードと反応ノードの間

RFC 7683では、報告ノードが過負荷を判断し、必要な削減率を決めてOLRを送る。その算定方法は実装に委ねられる。反応ノードは報告を受け取り、Overload Control State（OCS）を管理し、どの要求メッセージを軽減処理の対象にするかを決める。この選択方法も実装依存である。

既定のloss algorithmでは、要求された割合の新規要求に処理を適用しなければならない。ただし、無状態のアルゴリズムなので、送信トラフィックの絶対量が同じ割合だけ減るとは保証しない。保証されるのは、新規要求のうち指定された割合が処理対象として選ばれることだ。

しかも「処理」には複数の出口がある。要求は抑止されることも、別の宛先へ迂回されることもある。RFC 8581はpeer overloadの場合に迂回を優先し、代替peerの容量が不足すれば必要な要求を抑止するよう定める。保護対象への到着数が減っても、他のpeerへの負荷、再試行、エラー応答、遅延は増え得る。ゼロという結論は、どの観測点を指すかを決めない限り成立しない。

「すべて」を限定するOCS

RFC 7683のHost Reportはhost-routed requestに、Realm Reportはrealm-routed requestに適用される。OCSの対応付けにはApplication-IDも関わる。RFC 8581が追加したPeer Reportは、Application-IDと相手peerのDiameterIdentityで状態を識別する。

したがって、100が意味するのは、特定の有効なOCSに一致した要求のすべてである。別のapplication、host、realm、peerは範囲外になり得る。拡張を扱えない送信元は同じ状態を持たないかもしれない。Peer Reportでは、SourceID が応答を送ってきたpeerのDiameterIdentityと一致しなければ、反応ノードは報告を無視しなければならない。誤挿入や悪意ある挿入から制御を守るこの規則は、出所そのものが証拠項目であることを示す。

状態には版もある。大きい OC-Sequence-Number は対応するOCSを更新し、同じか小さい番号は古い報告として無視される。validity durationや削減率を変えるたびに番号を進める必要があり、以前の報告が有効な間は、報告ノードが再起動しても順序を保たなければならない。インシデント調査で必要なのは、送信ログ上の最新値ではなく、各反応ノードが要求を選んだ時点で受理していた版である。

OLRがない応答も状態を終わらせない

画面から警告フィールドが消えると、復旧と判断しがちだ。DOICの状態機械ではそうならない。応答に OC-OLR が含まれなくてもOCSは削除されず、OLRの欠如は「変更なし」を意味する。報告ノードはvalidity durationを0にした更新で終了を知らせることができ、状態は所定の時間切れでも終了する。

100パーセント削減からの退出も、一気に通常送信へ戻す操作ではない。RFC 7683は、再過負荷を招く急変を避けるため、probe messageなどで慎重に送信を再開するよう勧める。RFC 8581もPeer Reportに基づく軽減を制御された形で終える。終了通知、OCSの失効、試験的な再開、サービス回復は同じ時刻とは限らない。

最初にOLRが消えた応答へ「復旧」の縦線を引く運用は、状態を逆に読んでいる。OCSの失効時刻だけで利用者影響の終了を宣言する運用も、制御と成果を混ぜている。

三つの報告を足し算しない

RFC 8581では、一つのメッセージにHost、Realm、PeerのOverload Reportが同居し得る。反応ノードは先にHostまたはRealmの軽減を適用し、そこで残ったメッセージにPeerの軽減を行う。すでに処理された数も考慮し、負荷の振動を避ける。

各パーセントは独立した損失計ではない。元の要求数に三つの率を掛けたり、単純に合計したりすれば、仕様にない共通分母を作ってしまう。必要なのは、候補要求、一段目のOCSに一致した要求、その生存分、Peer OCSとの一致、迂回、抑止、通常送信という集合ごとの件数だ。百分率は、その母数と順序が残って初めて説明になる。

LoadとReductionでは目盛りの向きが違う

RFC 8583は、常に存在するloadと、例外状態であるoverloadを区別する。Load Reportは負荷分散などに使える情報、つまりhintである。OLRはoffered loadを減らすよう明示的に求めるもので、報告ノードと反応ノードの契約に近い。

数値の方向も反対だ。Diameter Loadは値が高いほど実負荷が低く、65535がzero load、0が100% loadを表す。一方、RFC 7683のReduction Percentageは0なら軽減不要、100なら一致する全要求を処理するよう求める。二つを無名の「負荷率」欄へ入れれば、構文上は正常なまま意味だけが反転する。

RFC 7068は、制御信号とは別に評価すべき指標を示す。負荷下のoverall useful throughputこそ、解決策の価値を測る最終的な尺度である。OLRは依頼を、OCSはノードの状態認識を、要求ログは選択を、カウンターは到着数を、アプリケーションテレメトリーは完了した有用な仕事を証明する。前段の資料だけで後段の成果を代用してはならない。

後から結べる受領記録

まず残すのは、報告判断の主体、Application-ID、report type、判断ロジックの版、計算時刻である。次に、sequence number、validity、algorithm、reduction percentage、送信時刻を含むOLRそのものを保存する。

反応ノード側では、機能対応を通知していたか、正しい送信元から受け取ったか、sequenceがOCSを作成または更新したか、それとも古いため無視されたか、有効と見なした区間はいつかを記録する。さらに、一致した各要求をOCSへ結び、normal routing、diversion、throttlingのどれを選んだかを残す。

その上で、保護ノードと代替peerの到着数、何もしなければ送ったはずの基準、拒否と再試行、有効スループット、アプリケーションの遅延や完了数を同じ時間窓で比較する。証拠が途切れたら、表現もそこで止める。「Node Aで100パーセントのOCSが有効だった」と言えても、「トラフィックはゼロだった」とは限らない。

情報源