要約

  • RFC 2214は、インターフェースごとのbacklog C、delay D、slack、RowStatusを、いずれもread-createのSNMPオブジェクトとして公開した。
  • その行が示すのは実装誤差とローカルな資源配分である。フローの通過、予約の継続、RFC 2212の合成された上限、実測遅延の達成までは示さない。

管理画面に四つの値が並ぶと、一つの証明書のように見える。backlogにはバイト、delayにはマイクロ秒、slackには余裕、statusには有効性がある。しかもRFC 2214では、四列すべてがread-createだった。読み取れるだけでなく、実装によっては管理側から作成できる。

しかし、この表が扱う対象は「保証の結果」ではない。Fred Baker、John Krawczyk、Arun Sastryが1997年9月に公表したRFC 2214は、Integrated Services MIBにGuaranteed Service固有のインターフェース属性を加えた。定量的なサービス境界を定義したのはRFC 2212であり、RFC 2214は現実の装置が理想モデルからどう外れるかを管理面に表した。

Cは現在のキュー長ではない

intSrvGuaranteedIfBacklogはCをバイト単位で表す。仕様は、厳密なbit-by-bit serviceから実装が外れることで生じるデータbacklogと説明する。packetized weighted fair queueingなら、最大パケットサイズを設定する例が示された。

RFC 2212でCは、予約レートに依存する誤差項である。遅延上限ではCを予約レートRで割る。データグラムのシリアライズのように、同じ量でも伝送速度によって時間への影響が変わるからだ。

したがって、SNMPで読んだCは、その瞬間にキュー内で待つバイト数ではない。単位がバイトであっても、これはテレメトリではなく、数理モデルに入る実装特性である。現在値と上限モデルを混同すれば、表は本来持たない観測能力を与えられてしまう。

Dは一つのパケットの測定値ではない

intSrvGuaranteedIfDelayはDをマイクロ秒で表す。Dはレートに依存しない要素ごとの誤差で、サービス要素を通る最悪の時間変動を表す。RFC 2214は、入力インターフェースからプロセッサを経て出力側へ至る内部時間や、Ethernetで最大回数の衝突が起きた場合を例に挙げた。

Dは一般に起動時または設定時に決まる。パケットに付いた実測タイムスタンプではない。エンドツーエンドの式に使うには、実際の経路に沿うCとDをCtot、Dtotへ合成しなければならない。RFC 2212は、この収集をsetup protocol、routing protocol、または別のmanagement functionに委ねている。

さらに保証には条件がある。トラフィックは規定に適合し、コンポーネント障害がなく、フローの存続中に経路が変わらないことが前提だ。制御されるのは最大キューイング遅延であり、平均や最小ではない。データグラム全体の最大遅延にはpath latencyも加える必要がある。インターフェース行だけでは、どの条件も確認できない。

slackは余りではなく、保存すべき決定だった

slackの規則は、管理状態の時間軸を示す。ネットワーク要素がフローiの予約資源を減らすためSiを使ったなら、そのSiを保存する。後続のreservation refreshを受けたときは再計算せず、同じSiを使わなければならない。目的は予約処理の一貫性である。

例では、S = Dreq - (b/r + Ctot/r + Dtot)で余裕を求める。中間要素はs <= Sを消費できる。RCSD schedulerならローカル遅延境界を増やし、WFQなら規則に従って予約レートを下げられる。全体の想定上限を増やさず、時間の余裕をローカル資源の節約に替える操作だ。

slackは空き帯域でも実測遅延でもない。使える遅延予算であり、すでに行った資源判断の記録でもある。refreshのたびに判断し直せば、同じ要求が異なる予約へ揺れる。Siの保存は、その揺れを止める。

ただしRFC 2214の行はifIndexで索引される。完全なフロー識別子やRSVPのPATH/RESV履歴、refreshの連続性は含まれない。一般のフロー表はRFC 2213、receiver-orientedなsoft stateはRFC 2205の領域である。一貫性を検証するには、別の証拠を結合する必要がある。

書き込み可能性は権限を示し、成果を示さない

Security Considerationsは重要な境界を置いた。SNMP SETは、RSVP negotiationとは異なる規則でRSVPまたはIntegrated Servicesの予約を生じさせ得る。

つまりSET成功は受信側の同意ではない。soft stateが維持されたこと、正しい主体がadmissionを受けたこと、classifierが対象パケットを選んだこと、schedulerが想定どおり動いたことも証明しない。

RowStatusも同様だ。RFC 2214では、Guaranteed Service用に設定されたインターフェースでstatusが有効になる。一般のRowStatusでactiveとは、conceptual rowがmanaged deviceで利用可能という意味にすぎない。経路全体の判定ではない。

RFC 2214が残したのは、保証を自動的に証明する表ではなく、誤差と裁量を可視化する帳簿だった。Cはレート依存の実装差、Dはレート非依存の時間差、slackは遅延余裕と資源の交換、statusは行の管理状態を示す。帳簿は宣言と選択を記録できる。実際の保証には、フロー、経路、合成、適合性、観測が別に必要である。

出典