Strict-priority DSCP scheduling · Per-class throughput, drops & latency as the link saturates
This simulator models how strict-priority DSCP queuing behaves as a WAN or campus link approaches saturation, showing per-class throughput, packet drops, and queuing latency in real time. Network engineers use it to understand how voice and video traffic is protected during congestion and to set appropriate bandwidth provisioning targets.
In strict-priority Low Latency Queuing (LLQ), traffic classes are served in DSCP priority order: EF voice (DSCP 46) is served first, then AF41 video (DSCP 34), then Best Effort data (DSCP 0). Each class is allocated bandwidth up to the remaining link capacity after higher-priority classes are served. When total offered load exceeds link capacity, the lowest-priority class absorbs all drops — protecting real-time traffic.
Queuing latency is approximated using an M/M/1 model: delay ≈ base_latency × ρ/(1−ρ), where ρ is the effective utilization seen by each class including all higher-priority traffic. This explains why voice latency remains low even during heavy congestion: its effective ρ only includes voice load, not video or data queues.
DSCP marking values are defined by RFC 4594 (Configuration Guidelines for DiffServ Service Classes). EF (Expedited Forwarding, DSCP 46) is mandatory for voice per RFC 3246. AF41 (DSCP 34) is the standard for interactive video. CS3 (DSCP 24) is used for signaling (SIP, H.323). RFC 2597 defines the Assured Forwarding per-hop behavior. ITU-T G.114 specifies one-way delay for voice must not exceed 150 ms for acceptable quality. IEEE 802.1p provides Layer 2 CoS marking (PCP bits) used within Ethernet switches before IP-based DSCP takes over.
Voice (EF) should not exceed 33% of link capacity in a strict-priority queue to prevent starvation of lower classes — this is Cisco's recommended ceiling. Video bandwidth should be planned with sufficient headroom since video codecs (H.264, H.265) produce variable bitrate traffic with bursts up to 3× average rate. Configure WRED (Weighted Random Early Detection) on the data class rather than tail-drop to reduce TCP synchronization and improve throughput fairness. Always set a queue depth limit (policer) on the EF class to prevent misconfigured or malicious VoIP traffic from consuming the entire link.
Set the link capacity to match your WAN circuit or uplink speed. Adjust the offered load sliders for each traffic class. Watch the per-class results panel to see throughput, drops, and latency. Increase data traffic beyond the link capacity and observe that voice and video are protected while data absorbs all drops. This demonstrates the value of QoS policies and helps set the baseline for capacity planning — the link needs upgrading when the data class carries significant production traffic and begins dropping regularly.
DSCP 46 (EF — Expedited Forwarding) per RFC 4594 and ITU-T G.711/G.729 deployment guides. EF provides the lowest queuing delay and jitter, ensuring voice one-way delay stays below the 150 ms ITU-T G.114 recommendation.
Tail-drop discards all packets when a queue is full, which causes TCP global synchronization (all TCP flows reduce window size simultaneously, creating a saw-tooth throughput pattern). WRED (Weighted Random Early Detection) probabilistically drops packets before queue fills, staggering TCP backoff and maintaining higher aggregate throughput.
Strict-priority scheduling serves higher-priority queues first and completely before lower-priority queues receive any service. EF and AF traffic consume their allocated bandwidth first; only remaining capacity is available for BE data. This guarantees voice and video quality at the expense of data throughput during congestion.
ITU-T G.114 and G.168 recommend jitter below 30 ms for acceptable VoIP quality. Most enterprise IP PBX systems have a jitter buffer of 20–50 ms. Sustained jitter above 50 ms causes audible artifacts (choppy audio, echo) and is the primary VoIP quality complaint in under-provisioned networks.
Both. Trust DSCP markings from phones and video endpoints at the access switch. At distribution and core, honor existing markings. At the WAN edge, apply policing (rate limiting per class) and re-mark any untrusted markings from the LAN before traffic traverses the WAN where QoS enforcement matters most.
Try our Enterprise IT Networks Studio
More calculators, simulators, and guides for this discipline.