要約

  • RFC 2212は、実際のネットワーク要素が理想的な流体サーバーから外れる最大量を、レート依存のC/Rとレート非依存のDで表した。
  • 各要素の誤差はCtotとDtotへ加算され、トラフィック記述と予約レートを合わせて最大キュー遅延を計算できた。
  • この上限は適合トラフィック、パケット長、アドミッション、資源、経路が有効な間だけ成立し、ゼロジッター、本人性、配送、アプリケーションの成功は証明しない。

slackから読むGuaranteed Service

RSpecは予約レートRとslack Sを持つ。RはTSpecのトークンレートr以上でなければならず、Sはゼロ以上の時間である。より大きなRを求めれば、一般にキュー遅延は小さくなる。より大きな遅延を許せる受信側は、その差をSとして示せる。

途中の要素は、slackの一部を使ってローカル予約を小さくできた。ただし、入力(Rin, Sin)を出力(Rout, Sout)へ変えるとき、次を守る必要があった。

Sout + b/Rout + Ctoti/Rout <= Sin + b/Rin + Ctoti/Rin

さらにr <= Rout <= Rinである。同じslackを更新のたびに計算し直して使うことは許されない。消費した量はその要素が保持し、次のrefreshでも一貫させる。

つまり、資源を節約する裁量はあっても、遅延制約を消す裁量はなかった。

何を流すかは五つの値で決まった

TSpecは、トークンレートr、バケット深さb、ピークレートp、最小ポリシング単位m、最大データグラム長Mからなる。

任意の時間Tで送出できる適合データ量は、次を超えない。

M + min[pT, rT + b - M]

小さなパケットは、ポリシング時には少なくともmとして数える。Mより大きなパケットは適合しない。要求したMがリンクMTUを超えるなら、フロー要求自体を拒否しなければならない。

この細かさには理由がある。予約の名前だけでは、どのバイトが保護対象か決まらない。トラフィックの形とパケット長が契約の一部だった。

理想の専用線と現実のパケット処理

RFC 2212はレートRの専用線を流体モデルとした。他のフローに邪魔されず、連続的にサービスを受ける仮想的な基準である。トークンバケット(r,b)に従うフローなら、R >= rのとき流体遅延はb/Rで抑えられる。

しかし実装はパケットをまとめて送る。スケジューラの順番を待ち、スロットを待ち、経路処理のためにサービスが途切れることもある。規格はその差を二種類に分けた。

Cはレート依存のバックログで、遅延への寄与はC/Rになる。パケット化の影響が代表例だ。Dはレートに依存しない最悪時のローカル変動で、待ちスロットやサービス中断の時間を含む。

一要素の単純な境界は次の形になる。

b/R + C/R + D

CとDは平均値ではなく最大値である。普段のパケットがもっと速く通っても、広告した誤差境界の意味は変わらない。

誤差は経路上で足し算された

各要素のCとDは加法的に合成される。セットアップ機構がCtotとDtotを端点へ渡せば、アプリケーションは経路の最大キュー遅延を求められた。

p > R >= rなら、境界は：

[(b-M)/R × (p-R)/(p-r)] + (M+Ctot)/R + Dtot

r <= p <= Rなら：

(M+Ctot)/R + Dtot

ピークレートを使わない保守的な形は：

b/R + Ctot/R + Dtot

式の構造が、帯域だけでは不十分な理由を示す。同じRでも、経路のCtotとDtotが違えば境界は違う。Rを増やせばCtot/Rは小さくなるが、Dtotは残る。

固定遅延と経路は別の所有物だった

式が制御するのはキュー遅延である。伝搬、伝送、固定処理のレイテンシは別に求め、最大エンドツーエンド遅延に足さなければならない。

経路もGuaranteed Serviceが決めるわけではない。セットアップまたはルーティング機構が選ぶ。RFC 2212がいう安定性は、エンドツーエンド経路が変わらない間に限られる。

したがって、CtotとDtotを保存しても、対応する経路と時刻を失えば現在の証拠にはならない。古い計算は数学的に正しくても、今のフローの計算ではないかもしれない。

CsumとDsumは整形点のための記憶

エンドツーエンド合計とは別に、直近のreshaping pointからの部分和CsumとDsumがある。これらは、適合トラフィックを元のTSpecへ戻すためのバッファを計算する。

ピークレートを利用しない保守的な必要量はb + Csum + Dsum × Rである。Csum/Dsumはパケット観測でも、もう一つのエンドツーエンド保証でもない。

TSpecが実トラフィックより小さければ、整形器には大きなキューができ、非適合パケットが生じる。ネットワーク境界では通常、それらをbest effortへ落とす。予約が存在することと、すべてのパケットが適合することは別だった。

最大値を保証してもジッターは残る

RFC 2212は、ジッターを最小化しないと明記した。制御するのは最大キュー遅延であり、最小遅延と最大遅延の差ではない。多くのパケットは期限よりかなり早く届き、受信側で再生時刻まで待つ可能性がある。

キュー溢れによる損失がないという約束も条件付きである。フローはTSpecに従い、予約はadmissionを通り、必要な全要素がサービスを提供または十分に模倣し、帯域とバッファが確保され、パケット長が範囲内で、障害や経路変更がない必要がある。

期限の上限は、等間隔配送でも平均遅延でもない。条件を外した瞬間に、同じ数字の証拠能力が変わる。

予約の成功とアプリの成功は別だった

RFC 2212はセットアップ手段を一つに限定しなかった。RSVP、手動設定、管理プロトコルのいずれでもよい。RFC 2210はRSVPのFLOWSPEC、SENDER_TSPEC、ADSPECを別に定義し、認証、会計、ポリシーもQoSオブジェクトとは別に扱った。

その結果、証拠の段階は明確になる。TSpecは送信側の記述、RSpecは受信側の要求、C/Dは要素のサービス特性、admissionは資源判断、式は条件付き上限、パケット測定は実際の通過、アプリケーションは最終結果である。

FLOWSPECが受理されても、その後の適合は証明されない。境界を計算しても、特定パケットの到着は証明されない。到着しても、送信者の本人性、利用権限、復号、再生、人の目的達成は証明されない。

RFC 2212は一つの段階を強くした。強くなった段階に、上位すべての権限を与えたわけではない。

情報源と証拠の限界

これらは公開されたサービス契約と分析上の境界を示す。特定製品、実ネットワーク、導入率、実測性能、後続QoS方式への直接の系譜は示さない。