a microburst

Imagine a normally quiet country lane that, for one second every few minutes, has a hundred cars roar past nose to tail before going empty again. If you measured traffic once a minute you would call the lane lightly used — yet for that one second it was completely jammed. A microburst is the network version: a sudden, very short spike of packets, lasting microseconds to a few milliseconds, that briefly overwhelms a link or buffer even though the link's average utilization looks comfortable.

Concretely, a microburst is a tiny window in which the instantaneous arrival rate of packets exceeds a switch port's capacity, so the excess must queue in the port's buffer. If the burst is big enough, the buffer fills and packets are dropped (tail drop). Microbursts are invisible to ordinary monitoring because tools usually report average rates over seconds, which smooth a microsecond spike into nothing — a port can show 30% average utilization while silently dropping packets during sub-millisecond bursts. They arise naturally in datacenters from synchronized senders (the same pattern behind incast), from the bursty output of high-speed network cards, and from many flows happening to peak at the same instant.

Why it matters: microbursts are a leading hidden cause of packet loss and latency spikes in datacenters, and they are maddening precisely because the averages look fine. They are why low-latency applications care about buffer occupancy and tail latency, not just mean throughput, and why congestion controls like DCTCP try to keep queues short so a sudden burst has somewhere to go. Mitigations include deeper or shared buffers, ECN-based early signaling, and careful traffic shaping. The honest caveat: you cannot manage what you cannot see — catching microbursts requires fine-grained telemetry (microsecond-resolution buffer and queue measurements), not the second-by-second averages most dashboards show.