queuing delay
You have stood in line at a checkout: if the store is quiet you breeze through, but if it is busy you wait behind others before it is your turn. Queuing delay is exactly that for a packet. When a packet arrives at a router but the outgoing link is already busy sending other packets, it waits in a buffer (a queue) until its turn — and that waiting time is the queuing delay.
Unlike the other delays, queuing delay is variable and depends on how busy the link is. If packets arrive faster than the link can send them, the queue grows and waits get longer; if traffic is light, the queue is often empty and the wait is near zero. The governing quantity is traffic intensity: the average arrival rate of bits divided by the link's service rate. As that ratio creeps toward 1 (the link nearing fully loaded), queuing delay does not rise gently — it blows up toward infinity. Push past 1 and the buffer overflows, so packets are not just delayed but dropped (lost) entirely.
Queuing delay is why your latency spikes when the network is congested even though distance and link speed have not changed, and it is the delay component that congestion control (in TCP) and quality-of-service mechanisms try to manage. A subtle modern problem is bufferbloat: oversized buffers that 'helpfully' avoid drops by holding huge queues, which trades packet loss for terrible, seconds-long latency.
On a link running at 90 percent load, a packet may wait behind dozens of others; nudge that to 99 percent and the queue, and the delay, can grow tenfold or worse — the same link, just busier.
The only delay that explodes near full load — and the one that turns into packet loss.
Queuing delay is the one delay component you can actually influence with traffic management, because it is the only one caused by contention rather than physics or fixed packet size.