What is Microbursts?
Updated: 3 days ago
Microbursts are very short spikes of network traffic that arrive faster than a bottleneck can forward them. They can briefly fill a queue and create latency, jitter or packet loss even when average utilisation looks perfectly normal. The important distinction is timescale: sustained congestion is visible over longer periods, while a microburst can begin and disappear between ordinary monitoring samples.
What is a microburst in networking?
RFC 8238 defines a microburst as a type of burst in which packet drops occur despite there being no sustained or noticeable congestion on the link or device. It also describes the traffic as not being evenly distributed across the measurement interval. See the IETF data centre benchmarking terminology in RFC 8238.
In practical broadband and Ethernet terms, think of packets arriving in a tight cluster. If their instantaneous arrival rate temporarily exceeds the rate at which the next link or interface can transmit them, the excess packets must wait in a queue. If the available queue cannot absorb the burst, packets can be dropped.
Microbursts versus sustained congestion
A microburst is short lived and may disappear before a coarse monitoring interval records it.
Sustained congestion persists because offered traffic continues to meet or exceed available capacity.
Both can create queues, latency and loss, but their timing and diagnostic signatures differ.
Low average utilisation does not prove that microbursts are absent.
For the wider capacity concept, see What is Bandwidth?. For persistent demand exceeding capacity, see What is Network Congestion?.
Why average bandwidth graphs can miss microbursts
A utilisation graph averages traffic over its sampling interval. A one second, five second or one minute average can therefore hide activity that happened over milliseconds or microseconds.
For example, a port might be lightly used for most of a second but receive a dense packet burst during a tiny part of that second. The one second average can remain modest even though the queue experienced intense short term pressure.
This is why diagnosing microbursts requires sufficiently fine telemetry, queue counters, drop counters or packet level observation rather than relying only on long interval bandwidth charts.
Techie Broadband microburst calculation
Consider a theoretical bottleneck with 10 Gbps of traffic arriving towards a 1 Gbps egress link for 1 millisecond. This is deliberately simplified to show the mathematics.
Data arriving in 1 ms at 10 Gbps: 10,000,000,000 × 0.001 = 10,000,000 bits, or 10 Mb.
Data the 1 Gbps egress can transmit in the same 1 ms: 1,000,000 bits, or 1 Mb.
Temporary excess: 9 Mb.
9 Mb ÷ 8 = 1.125 MB of temporary queue pressure, ignoring framing and other implementation details.
This is a Techie Broadband theoretical calculation, not a measured UK broadband statistic. The example shows why a very short rate mismatch can consume meaningful buffer space even though it barely changes a long term utilisation average.
What causes microbursts?
Bursty packet delivery is normal in packet networks. RFC 8337 explains that TCP slow start, delayed acknowledgements, TCP segmentation offload, application pauses and other mechanisms can produce bursts. See the IETF Model-Based Metrics discussion of sender bursts.
Multiple flows becoming active at almost the same time.
TCP slow start and ACK clock behaviour.
TCP segmentation offload and other sender efficiency mechanisms.
Applications releasing buffered data in batches.
Traffic converging from several faster interfaces towards a slower egress.
Scheduling behaviour in switches, routers, wireless networks or hosts.
Cloud, backup or storage workloads generating short high rate transfers.
Where a microburst becomes a problem
A burst is not automatically harmful. The network needs some buffering specifically to absorb short variations in packet arrival rate. Problems appear when the burst exceeds the capacity available at the relevant queue, or when the resulting queue delay harms time sensitive traffic.
RFC 7567 explains that buffering is intended to absorb bursts and transmit them during subsequent quieter periods, while warning that a large burst can delay other packets and reduce the performance of flows sharing the bottleneck. See the IETF Active Queue Management recommendations.
Microbursts and queue depth
Microbursts and Queue Depth are tightly connected. Queue depth describes how much traffic is waiting. A microburst can make queue depth rise sharply for a short period, then fall again once the egress link catches up.
A queue with enough temporary capacity may absorb the burst without loss, but packets still spend time waiting. A smaller or already occupied queue may overflow sooner. More buffering is not automatically better because excessive unmanaged buffering can increase delay.
Microbursts, latency and jitter
When packets wait behind a burst, their delay rises. If the amount of waiting changes rapidly, delay variation rises as well. That means a microburst can create a short latency or jitter spike without causing a sustained fall in throughput.
See What is Latency Under Load? for delay while a connection is busy and What is Round Trip Time (RTT)? for the round trip measurement itself.
Microbursts and packet loss
If the relevant queue has no remaining capacity when more packets arrive, packets can be dropped. This can happen quickly enough that a user sees retransmissions or an application stutter while an ordinary utilisation graph still looks unremarkable.
Packet loss caused by a microburst is therefore not evidence by itself that a link was continuously saturated. It can indicate that short term offered load exceeded the combination of egress capacity and available buffering.
Microbursts and bufferbloat are not the same thing
A microburst is a short concentration of packet arrivals. Bufferbloat is excessive delay associated with oversized or poorly managed queues. A network needs enough buffering to absorb useful bursts, but queues should not remain persistently bloated.
RFC 7567 explicitly notes the tension: queues should normally remain small while retaining enough capacity to absorb bursts. The objective is not simply the largest possible buffer.
Why microbursts matter on fast home broadband
Faster FTTP and multi gigabit services can move bottlenecks into the home network. A 2.5 Gbps WAN feeding a 1 Gbps LAN port, for example, creates a rate transition. Several fast devices converging on one slower interface can do the same.
This does not mean multi gigabit broadband inherently creates microbursts. It means that rate transitions, aggregation and traffic convergence deserve attention when diagnosing short lived queue pressure.
Microbursts on WiFi
WiFi adds another form of variable service rate because devices contend for shared airtime and the radio rate can change. Packets may accumulate while a station waits for transmission opportunities, then be released in groups.
If a problem appears only over WiFi, repeat the test over wired Ethernet before attributing it to the broadband service. Wireless retransmissions and contention can create symptoms that resemble wider network congestion.
Microbursts on UK FTTP, FTTC and cable
The concept is independent of one access technology. FTTP, FTTC, cable, fixed wireless and mobile networks all contain queues and rate transitions. The location and behaviour of those queues differ.
For UK broadband diagnosis, always separate ISP, access network, retail product and location. Do not assume that two products sold under the same provider name have identical capacity, upload ratios or queue behaviour.
Can a speed test detect microbursts?
A normal speed test is mainly designed to estimate throughput over a longer interval. It can expose symptoms such as packet loss or latency under load, but it is not automatically a microburst detector.
A microburst investigation benefits from high resolution interface counters, queue occupancy telemetry, drop counters, ECN information where available, or packet captures with accurate timestamps. Consumer routers vary greatly in what they expose.
How to investigate suspected microbursts
Reproduce the symptom and note its exact timing.
Test over wired Ethernet to remove WiFi as the first variable.
Confirm WAN, LAN and switch interface rates and look for rate transitions.
Check interface error and packet drop counters before and after the event.
Inspect queue or QoS statistics if the router or switch exposes them.
Use higher resolution traffic telemetry rather than only minute averages.
Capture packets close to the suspected bottleneck where practical.
Look for simultaneous flows or applications that start in bursts.
Compare idle and loaded latency to identify short queueing spikes.
Repeat with one suspected traffic source paused, then compare the result.
The objective is to find the bottleneck and the timescale. Do not automatically blame the ISP before local Ethernet, WiFi, router processing and traffic sources have been eliminated.
Can Active Queue Management help?
Active Queue Management can improve how queues behave under pressure. RFC 7567 recommends AQM approaches that manage queue occupancy and delay rather than relying solely on a queue becoming completely full.
AQM does not make physical capacity unlimited. It aims to control the consequences of queue build up. Router implementations, algorithms and processing capacity vary, particularly at gigabit and multi gigabit rates.
Microbursts versus burst speed
Microbursts should not be confused with Burst Speed. Burst speed describes a short term observed data rate that may exceed a longer sustained rate. A networking microburst describes a tightly concentrated arrival of packets that can stress a queue. They can coexist, but they describe different things.
Microbursts versus sustained throughput
A connection can deliver strong sustained throughput and still experience occasional microbursts. Sustained throughput describes what can be maintained over time. Microbursts are about very short timescale arrival patterns.
Frequently asked questions about microbursts
How long does a microburst last?
There is no single universal duration that defines every operational use of the term. The key characteristic is that the burst is short enough not to appear as sustained congestion and may be missed by coarse monitoring. RFC 8238 defines it through burst behaviour and packet drops rather than assigning one fixed duration.
Can microbursts happen when average utilisation is low?
Yes. Average utilisation can be low because the burst occupies only a tiny fraction of the averaging interval.
Do microbursts always cause packet loss?
No. A queue can absorb a burst if sufficient capacity is available. The burst may instead create temporary queueing delay, or it may have little observable impact.
Are microbursts only a data centre problem?
No. The term is prominent in switching and data centre benchmarking, but the underlying phenomenon of short packet bursts meeting a bottleneck can occur anywhere packet traffic converges or changes rate, including home and broadband networks.
Will a bigger buffer solve microbursts?
Not universally. Sufficient buffering can absorb bursts, but excessive unmanaged buffering can increase latency. Buffer capacity and queue management need to be considered together.
Can microbursts affect gaming and video calls?
Yes, if they create enough queueing delay, jitter or loss at a shared bottleneck. The impact depends on burst size, queue state, traffic priority, application tolerance and where the bottleneck sits.
Key takeaway
Microbursts are short, intense concentrations of packet traffic. They matter because a bottleneck must deal with instantaneous arrivals, not merely a comfortable looking average utilisation figure. Diagnose them by examining queue pressure, drops and timing at sufficiently fine resolution, then work from the local network outward. The important questions are where the rate transition occurs, how large the temporary excess is, whether the queue absorbs it, and what happens to latency, jitter and packet delivery while it clears.
To explore the related technical concepts used in this Microbursts guide, visit our broadband terminology guide.
