Summary

  • 11月2日付のIPFIXマイクロバースト草案は、出口キューと測定期間ごとに、検出したイベントの総数と、そのうち輻輳に伴うパケット損失が一度でも起きたイベント数を提案する。
  • 検出条件は装置側で決める。損失イベントの数は失われたパケットの数ではない。後者には既存の別フィールドを使う。

設備の月次報告は余裕を示している。ところが出口の一つのキューでは、採取間隔の間に到着が処理能力を超えたかもしれない。長い平均に押しつぶされた短い山を、新しい草案は出口キューと時間窓の単位で記録しようとする。IETFの文書記録では、これは11月2日に提出された個人Internet-Draftである。

監視対象の識別には、IPFIXメッセージヘッダーのObservation Domain IDに加え、observationPointId、egressInterface、新設案の装置内egressQueueIdを組み合わせる。既存のミリ秒単位の開始・終了時刻が測定窓を囲む。ポート全体の平均だけでは、どのキューに圧力が集中したか分からない。RFC 7011がIPFIXのメッセージと観測ドメインを定義し、IANAの登録簿には再利用されるインターフェース、観測点、廃棄パケット、時刻のフィールドが載る。

提案される二つの新しいカウンターは別の単位を数える。microburstEventDeltaCountは検出イベント数、microburstLossEventDeltaCountは少なくとも一つの輻輳損失を含むイベント数だ。後者から失ったパケット総数は読めない。草案は既存のdroppedPacketDeltaCountも使い、パケット廃棄を別に示す。キューが一瞬満ちても損失が出るとは限らない。イベントをそのまま損失パケットとして請求すれば、単位を取り違えた設備計画になる。

イベントの入口は装置の設定にある。草案はキュー占有量の上昇・下降しきい値を一般的な方法として挙げるが、値、バッファーの基準、検出方式は統一しない。同じ圧力でも二つの装置が異なる数を出しうる。装置間比較には設定したしきい値と参照したバッファー容量を並べるべきだ。管理面への集計送出は分析と計画のためで、データ・オプションのテンプレート、セキュリティ、IANAに関する節はなお未記入だ。

公式資料には、キュー占有量、検出設定、送出レコード、実際の廃棄を結んだ特定装置の記録がない。それがあれば、提案フィールドによる容量判断を検証できる。