Summary

  • 11 月 2 日的 IPFIX 微突发草案提出按出口队列与测量时间窗导出两个新计数：检测到的微突发事件，以及其中至少发生过一次拥塞丢包的事件。
  • 是否达到微突发条件由本地队列占用阈值决定。“发生丢包的事件数”不是“丢弃的数据包数”；后者由另一个现有字段记录。

月报说链路有余量，现场的队列却可能在一瞬间排满。到达速率短时超过队列服务速率，平均值把尖峰摊进漫长的时间段，画出一条温顺的线。新草案原文要求把观测位置压到出口队列，把时间压到测量窗。IETF 文档记录显示这是一份 11 月 2 日提交的个人互联网草案。

一条记录的身份由 IPFIX 报文头中的 Observation Domain ID、observationPointId、egressInterface 和新提议的设备本地 egressQueueId 共同确定。已有的毫秒级起止字段划定测量窗。整条接口的平均负载无法指明究竟是哪一条输出队列在挨挤；队列编号让压力落到具体位置。RFC 7011给出 IPFIX 报文和观测域的基础，IANA IPFIX 登记表列出草案复用的接口、观测点、丢包与时间字段。

两个新增计数回答不同问题。microburstEventDeltaCount 是时间窗内检测到的微突发次数。microburstLossEventDeltaCount 是其中发生至少一次拥塞丢包的事件次数。第二个数字不会告诉你到底丢了多少包；现有的 droppedPacketDeltaCount 才是单独的丢弃包计数。草案也明确，微突发可以把队列短暂填满而不造成丢包。把事件数写成包数，会凭空放大损失。

事件是否成立，取决于本地检测规则。草案提到常见做法是为队列占用率设置上升与下降阈值，单位可以是字节，也可以是缓冲区比例；它没有规定统一的百分比、缓冲区模型或检测算法。两个设备面对相似流量，也可能报出不同的事件数。跨设备比较必须附上阈值与缓冲区参照，否则“最严重”的队列也许只是报警器最敏感的队列。

这份提案面向管理平面的汇总分析和规划。数据或选项模板、安全与 IANA 章节仍写着待定。官方文件没有一条具名实现轨迹，同时给出原始队列占用、检测配置、导出记录与实际丢包；这样的轨迹才能检验这些字段能否支撑扩容判断。