QoS Queue Starvation Under Burst with WRED
An edge router uses a 1G uplink with 8 egress queues. Queue 7 (EF, voice) is strict-priority; queues 0-6 are WFQ. A new bulk backup flow is classified into queue 3 with a committed rate but no policing. During nightly backup, voice quality degrades (jitter, drops) and display qos queue statistics interface shows queue 7 drops rising while queue 3 is near its WFQ weight. Total offered load is ~1.3G. WRED is enabled on queues 0-5 but not on 6-7. The voice flow is ~30M, well under 1G. Buffer per queue is default.
1. Explain how voice can drop on a strict-priority queue when it is only 30M on a 1G link.
Read the worked answer
Counter-intuitive but explainable: Strict-priority (SP) guarantees scheduling precedence, not buffer availability. Two mechanisms cause the drops:
- Shared/global buffer exhaustion: If the egress buffer pool is shared and queues 0-6 (especially the un-policed backup in queue 3) fill the pool, the SP queue 7 can be denied buffer when a burst arrives, even though it is scheduled first.
display qos queue statisticsshowing queue 7 drops while queue 3 is active supports shared-buffer pressure. - Microbursts + default small queue-7 buffer: Voice is low-rate but bursty (talk spurts, silence suppression). If queue 7's buffer is default-small and the uplink is momentarily saturated by a 1.3G offered burst, packets arriving during the saturation window are tail-dropped before the scheduler drains them. 30M average does not mean 30M instantaneous.
Why WRED on 0-5 matters: WRED on queues 0-5 should pre-drop the backup before global buffer pressure builds - but if queue 3 is not effectively using WRED (e.g., wrong thresholds or the flow bursts past them), the backup still fills buffers. SP has no WRED (correctly), so queue 7 has no early-drop protection; it relies entirely on buffer reservation.
2. Recommend a QoS design change and the verification commands.
Read the worked answer
Design change:
- Reserve buffer for the SP queue: configure a minimum guaranteed buffer / dedicated buffer for queue 7 so voice is never starved by shared-pool pressure.
- Police the backup flow into queue 3 to its committed rate (or lower WFQ weight) so it cannot consume the shared pool; rely on WRED with tuned min/max thresholds on queue 3 to pre-drop.
- Consider SP+WFQ with a bandwidth cap on SP (
qos queue spwith a max rate) so a misbehaving SP flow cannot starve others - but keep voice within the cap.
Verification:
display qos queue statistics interface <if>- queue 7 drops should fall to ~0; queue 3 WRED early-drops should rise (expected, desirable).display qos queue buffer(or platform equivalent) - confirm reserved buffer for queue 7.- End-to-end: measure voice jitter/loss with a test call during simulated backup load.
Trade-off: Policing the backup slows it (acceptable - it is bulk); reserving buffer reduces buffer available to other queues, so tune WRED on 0-5 to compensate.