What is microburst detection methodology at hardware switch level?
In the high-speed world of database clusters and NVMe-over-Fabrics, a network "outage" is rarely a cut cable. Instead, it’s a Microburst—a massive spike in traffic that lasts for only a few microseconds, perfectly invisible to standard monitoring tools like SNMP or top, but devastating to application latency.
If your monitoring interval is 1 minute (or even 1 second), a 50-microsecond burst that fills a switch buffer is "averaged out" into a flat, healthy-looking line. To see the truth, you have to move the detection methodology into the Switch Silicon (ASIC).
Standard network monitoring relies on Counters. Every 60 seconds, a monitoring agent asks the switch, "How many bytes did you send?"
The Math: If a 100Gbps port sends 1GB of data in 1 minute, the utilization looks like ~1.3%.
The Reality: That 1GB might have arrived in a single 10-millisecond burst. During that 10ms, the port was at 100% utilization, the buffers overflowed, and 5,000 database packets were dropped.
Microburst detection is the art of monitoring the "Buffer Occupancy" in real-time at the nanosecond level.
Modern switching ASICs (like Broadcom Tomahawk/Jericho, Cisco CloudScale, or Mellanox Spectrum) use three primary hardware methods to detect these bursts:
The switch hardware maintains a register that records the maximum buffer depth reached since the last poll.
The Detection: Even if the buffer is currently empty, the "Peak" register tells you that 50 microseconds ago, the buffer hit 95% capacity.
The Benefit: Low overhead; provides a "smoking gun" that a burst occurred between monitoring cycles.
Instead of waiting to be "polled," the switch hardware actively inserts metadata into the packets themselves as they pass through.
The Detection: As a packet leaves the switch, the ASIC attaches a small header containing the current queue latency and buffer utilization.
The Benefit: The destination (the database server) sees the "health" of every switch in the path for every single packet. This is how DCQCN (RoCE congestion control) works.
Some switches can be configured to "Mirror" a packet to a specialized analytics engine (like Broadcom Mirror-on-Drop) the moment a buffer threshold is crossed.
The Detection: The ASIC detects a "Queue Full" event and immediately sends a copy of the offending packets (and the queue state) to an external collector.
The Benefit: It tells you not just that a burst happened, but which application (IP/Port) caused it.
| Method | Resolution | Detects Microbursts? | Overhead |
| SNMP Polling | 1 - 60 Seconds | No (Averages everything) | Very Low |
| sFlow / Sampling | 1 in 1000 Packets | Partially (Might miss the burst) | Low |
| Hardware Watermarks | Nanoseconds | Yes (Peak tracking) | Low |
| Streaming Telemetry | Per-Packet | Yes (Full visibility) | High (Requires ASIC support) |
Microbursts are the primary cause of "Tail Latency" ($p99.9$).
The Burst: An RMAN backup or a VM migration sends a burst of packets.
The Buffer: The switch buffer fills up instantly.
The Victim: A tiny, critical 1KB "Commit" packet from Node A to Node B arrives at the switch and finds the door shut.
The Result: The packet is dropped or delayed by $2,000\mu\text{s}$ while the buffer drains. The user sees a random "hang" in the application.
To stop being blind to microbursts, your hardware strategy should include:
Configure Threshold Alerts: Set your switch to trigger an SNMP Trap or Log entry when a specific egress queue exceeds a "High Watermark" (e.g., 50% buffer capacity).
Buffer Monitoring (Histogram): Use switches that support "Buffer Histograms," which show you a distribution of how long queues stayed at certain depths.
Deep Buffers vs. Shallow Buffers: For "Burst-Heavy" database traffic (like Hadoop or Big Data), use switches with "Deep Buffers" (MBs instead of KBs) to absorb the burst. For "Latency-Critical" traffic (OLTP), use "Shallow Buffers" with ECN to signal the sender to slow down before the burst becomes a drop.
Microburst detection is about looking at the valleys and peaks, not the average. If you only look at 1-minute averages, your network will always look healthy while your database is dying. By leveraging Hardware Watermarks and Streaming Telemetry, you can finally see the $50\mu\text{s}$ spikes that are actually responsible for your application "hiccups."