Summary

  • The 2 November IPFIX microburst draft proposes counts per egress queue and measurement window: all detected microburst events and the subset of events during which at least one congestion-related packet was lost.
  • A local queue-occupancy condition decides what qualifies as a burst. The event-with-loss count counts events, not packets; the existing droppedPacketDeltaCount is a separate packet measure.

The link's monthly utilization report looks comfortable. A queue can still fill between two samples. Arriving traffic briefly outruns that queue's service rate, and the short collision is washed out by a longer average. The new draft asks IPFIX to carry a narrower receipt: what happened at which egress queue, over which window, and how many detected bursts included loss. The IETF record dates it to 2 November and lists it as an individual Internet-Draft.

The proposal identifies a monitoring instance through the Observation Domain ID in the IPFIX message header, observationPointId, egressInterface and a proposed device-local egressQueueId. Existing millisecond interval fields mark the beginning and end of the measurement window. Those coordinates matter: the average utilization of a whole interface cannot tell an operator whether one output queue was repeatedly pressed to its limit. RFC 7011 supplies the IPFIX message and observation-domain model, while the IANA registry already lists the reused interface, observation-point, packet-drop and interval fields.

Two proposed new counters answer different questions. microburstEventDeltaCount counts bursts detected in the window. microburstLossEventDeltaCount counts bursts during which at least one congestion-related packet was lost. The second counter counts events with loss, regardless of how many packets disappeared in each one. The draft also reuses droppedPacketDeltaCount for a packet-drop count within the measurement window. Treating those three values as interchangeable would turn a queue alarm into an invented loss total.

The detector is where the apparently clean count gets its politics. The draft describes common rising and falling queue-occupancy thresholds, but sets no universal percentage, buffer model or algorithm. One device can mark a burst sooner than another even when both emit a valid IPFIX record. A management system comparing event totals across queues or vendors needs the configured threshold and actual buffer reference beside each record. Otherwise the busiest-looking queue may simply have the most sensitive alarm.

The proposal itself separates transient queue filling from packet loss: a microburst can fill a queue without dropping traffic. It also distinguishes management-plane aggregates for planning from instant reaction signals. Its Data/Option Template, IANA and security sections are still marked TBD. A named implementation trace with raw queue occupancy, detection settings, exported records and observed drops would show whether these fields support a capacity or QoS decision.