要約

  • RFC 9808は、下流CDNがフットプリント別の超過不可容量と、それに対応する利用状況テレメトリーを上流CDNへ通知するための語彙を定めた。通知は助言であり、保証、確約、予約ではない。
  • 判断に必要なのは最大値一つではない。適用される全制約、ソフト上限とハード上限、TTL、測定元、指標、時間粒度、平均か分位点か、遅延、再委任分の集計、上流のルーティング規則を保存し、その後の受付・配信・品質・契約上の責任と分けて検証する必要がある。

午後2時、ある制御系が「ハード上限」を取得したとする。その広告のTTLは30分で、利用状況は5分窓の集計、観測遅延は2分だった。午後2時20分でも上限は有効である。しかし午後2時20分の画面に出る値が示すのは、もっと前の時間帯をまとめた状態だ。広告が新しいことと、余力が今も存在することは同義ではない。

これは実在のCDNや配信を述べる例ではない。RFC 9808にも、特定事業者がこの拡張を実装し、容量を確保し、要求を処理したという証拠はない。規格が与えるのは、独立したネットワーク同士が「上限」と「観測」を同じ意味で扱うための構文である。

2025年7月にStandards Trackとして公開されたRFC 9808は、RFC 8008のFootprint & Capabilities Advertisement Interfaceを拡張し、FCI.CapacityLimitsとFCI.Telemetryを追加した。RFC Editorの情報ページとIETF Datatrackerは、著者Andrew Ryan、Ben Rosenblum、Nir B. Sopherと文書の履歴を記録する。IANAのCDNI Parametersレジストリは、ペイロード、テレメトリー元、容量制限の共通名称を保持する。

共通語彙の利点は小さくない。「空きがある」という人間向けの一文だけでは、単位、対象地域、観測窓、更新時刻、測定主体、失効条件が分からない。構造化された通知なら、上流CDNの要求ルーターは同じ指標を継続的に参照し、どの制約が判断を変えたかを記録できる。異なる運用主体が私的な字段の意味を毎回交渉する必要も減る。

ただし、その可搬性は権限を広げない。RFC 9808は容量情報をadvisoryとし、保証、確約、予約ではないと明記する。下流CDNが一定範囲で利用可能と見積もる最大量を示しても、その一部が特定上流のため排他的に保持されたとは言えない。後で到着する個別要求が受け付けられることも、配信品質も、違反時の救済も決まらない。

この境界はCDNIの役割分担に沿っている。RFC 6707では、Content Service Providerと権威CDNの関係、さらに権威・上流CDNが下流CDNへ一部トラフィックを委ねる関係が整理される。だが価格、優先順位、排他性、補償などの商取引条件は技術仕様の外にある。プロトコル上の容量値をSLAと読むと、技術的主張で契約上の証拠を代用してしまう。

RFC 7336が示すCDNIフレームワークでも、要求ルーティングは上流側の局所判断である。RFC 9808はその入力を改善するが、決定権を下流へ移さない。上流は需要予測、観測遅延、失敗時の影響、別経路、自身の安全余裕を加味し、委任するか、いつ、どれだけ委任するかを選ぶ。妥当な広告は満杯まで送れという命令ではない。

容量は一つの数ではなく、同時に成立すべき制約の集合である。登録された型は、egress、requests、storage size、storage objects、sessions、cache sizeの六つ。帯域に余裕があっても、セッション状態が限界なら新しい接続は安全に増やせない。ストレージ容量に空きがあっても、オブジェクト数の上限が先に効くことがある。

そのためRFC 9808は、適用されるすべての制約を論理ANDで評価するよう求める。最も限定的に見える一項だけでも、最も都合のよい一項だけでもない。ダッシュボードが大きなegress値だけを前面に出すと、実際の拘束条件を隠し、存在しない余力を作る。

各制限には必須のmaximum-hardがあり、利用可能な最大容量を表す。任意のmaximum-softはそれより小さく、ハード上限へ達する前に上流がトラフィックを減らす地点になる。省略時はソフト値がハード値と同じになる。二つの値の差は単なる表示上の色分けではなく、観測と制御の遅れを吸収する余白である。

適切な余白は対象によって異なる。要求数は急増しやすく、長いセッションは一度受け付けるとすぐには減らない。キャッシュへの書き込みやオブジェクト数にも異なる慣性がある。計測が遅く、制御周期が長い系でソフト値をハード値に近づければ、反応が届く前に外縁を越え得る。固定比率ではなく、増加速度、遅延、制御周期、拒否コストから決めるべきである。

数値はフットプリントからも切り離せない。RFC 8008はアドレス、ASN、国、その他の登録済み型による範囲を扱い、複数条件が累積的に候補を狭めることを認める。毎秒一万要求という上限があっても、それが一国向けなのか、一つのアドレス集合なのか、条件の交差部分なのかで意味は変わる。範囲外の要求にはその数値を適用できない。

鮮度は別の軸である。容量制限はHTTP Cache-Controlなど基礎となる転送のTTLを継承する。TTL機構がなければ、当事者が帯域外で寿命を合意する。規格が想定する上限は比較的長く使える合理的なピーク目標であり、現在の利用率はそれより速く変わる。期限内の広告と、現在の空きは別々に取得しなければならない。

そこでFCI.Telemetryが機能する。これは特定の上流・下流委任関係について、下流の近リアルタイム集約利用状況を提供する測定元を通知する。source-idは広告内で一意であり、同じ参照先なら広告をまたいで安定している必要がある。metric名も同様だ。容量項目がsource-idとmetricを参照することで、上流は似た名前の別カウンターではなく、意図された測定と上限を比較できる。

time-granularityは値が表す時間区間を示す。data-percentileがあれば分位点、なければ区間平均である。latencyは現実からどれだけ遅れて値が届くかを表す。五分間の95パーセンタイルと一分間平均は、同じ数値でも同じ意味ではない。宣言遅延が同じでも、取得失敗や処理待ちで判断時の実年齢はさらに増える可能性がある。

genericなテレメトリー元は、具体的なアクセス設定を帯域外に残す。これは欠落ではなく境界設計である。規格は参照の同一性と比較可能性を共有しつつ、転送方式、資格情報、費用、安全境界まで中央化しない。運用リスクを負う当事者が、その後の選択を保持する。

再委任がある場合、利用量の集計も重要になる。複数CDNを通ってトラフィックが配信され、上流が総利用量を報告するよう求められたなら、下流側の利用も集約しなければならない。自ら直接処理した量だけを見れば、委ねた分が消え、実際には上限へ近づいているのに余力があるように見える。測定台帳は最初の一辺ではなく委任グラフを追う必要がある。

簡単な場合のためにinlineのcurrent値もあるが、急速に変わる利用率をキャッシュ可能な容量広告へ埋め込むことは推奨されない。比較的安定した封筒と頻繁に読む状態を分ける設計は、更新周期を明確にする。代わりに運用者は、テレメトリーが古い、取得不能、名称変更、想定外の粒度になった場合の動作を明示しなければならない。

最後の好都合な値を黙って再利用するのは判断ではない。上流は容量を減額し、新規委任を停止し、合意済み静的値へ戻し、あるいは低影響トラフィックだけを続けられる。正解は失敗モデルで変わる。RFC 9808はその方針を実装する材料を与えるが、選択は行わない。

委任後にも証拠の段差が残る。下流は現時点のキュー、コンテンツ、ポリシーに照らして個別要求を受け付ける必要がある。RFC 8006に関連するメタデータやコンテンツ取得の条件もある。その後に初めて配信バイト、継続セッション、遅延、完了、品質が観測される。元の容量広告はこれらの結果を内包しない。

RFC 8007が別のトリガー・状態インターフェースを定めていることも示唆的である。命令の受付、処理、効果の観測には別々のライフサイクルがある。容量でも「通知済み、測定済み、委任済み、受付済み、配信済み、体験済み」を一つの緑色表示にまとめてはならない。

監査証跡には、FCI文書そのもの、取得時刻、フットプリント、TTL、全制限、soft/hard値、source-id、metric、観測時刻、粒度、平均または分位点、遅延、総利用量の集約方法を残す。次に要求ルーターの版、安全余裕、予測、委任量と理由を加える。下流受付、実配信、品質、契約条項は後段の独立記録である。

Heng Luの「最小初期仕様」は、共有層を移植可能な最小語彙に留め、結果を負う主体へ将来判断を残す構造を説明する。「現実のレイヤー」に従えば、記号としての上限を技術状態、実行、成果へ昇格させずに済む。「動くコードを第一に」が問うのは、実際の制御器が取得、期限判定、比較、執行を行い、配信系がその後何をしたかである。

RFC 9808が標準化したのは、容量を語る方法であって容量そのものではない。通知、測定、委任、受付、配信、体験、救済という七つの動詞を、七つの証拠として扱う必要がある。新しい二つのオブジェクトが担うのは最初の二つだけだ。

情報源