Every QoS guide starts with classification and ends with queuing, and most deployments skip the step that actually makes any of it work: shaping the interface to slightly below the circuit rate.
Without a shaper, a router transmits at line rate, the ISP drops what it cannot carry, and your carefully marked voice packets are dropped by someone who never saw the markings.
Where congestion actually happens
| Link | Typical utilization | Congestion |
|---|---|---|
| Access switch to AP | 1 Gbps | Rare |
| Building uplink | 10 Gbps | Rare |
| Core | 40 Gbps | Rare |
| WAN circuit | 100 Mbps–1 Gbps | Daily |
The WAN is one or two orders of magnitude smaller than everything behind it. That is the only place where queuing has a job.
The shaper and the queue
LAN 1 Gbps → [ shaper 95% of 200 Mbps ] → [ priority queue ] → WAN 200 Mbps
Two details:
- Shape below the circuit rate (95–98%). If you shape at exactly 200 Mbps, the ISP's policer still drops bursts before your queue drains.
- The shaper creates the backlog that the scheduler reorders. Without it, there is no queue to prioritize.
Ingress is different
You cannot shape traffic you have not yet sent. Inbound congestion is handled by:
- Policing at the ISP (drops, no queue).
- TCP backpressure — dropping inbound packets makes senders slow down, which is crude but effective.
- Ingress policing with re-marking, then shaping on the way back out.
Most districts should focus on egress and accept that inbound is the ISP's problem to police.
The ISP may ignore your markings
DSCP is often trusted only within your own network. An ISP can re-mark everything to zero, or treat all traffic equally. Test it: send marked traffic and check what arrives at a remote endpoint. If the markings are stripped, your edge QoS only protects the path to the ISP, not across it.
Worked example: 200 Mbps circuit
| Class | Traffic | Treatment |
|---|---|---|
| Priority | Voice RTP | Strict priority, capped at 10% |
| Video | Conferencing | 30% bandwidth, low latency queue |
| Business | SIS, email, admin | 40% |
| Bulk | Backups, updates | 20%, deprioritized |
| Default | Everything else | Remainder |
Rules that keep it sane:
- Cap the priority queue. Uncapped strict priority starves everything else.
- Reserve bandwidth for bulk, or it will be starved permanently and never finish.
- Shape at 190 Mbps on a 200 Mbps circuit.
Measure before and after
| Metric | Before | Target |
|---|---|---|
| Voice MOS | 3.6 under load | 4.2+ |
| Jitter | 40 ms | under 20 ms |
| Bulk throughput | 200 Mbps | 150 Mbps during peak |
| Web TTFB p95 | 1.8 s | under 800 ms |
If the numbers do not move, the shaper is not in the path, or the markings are not matching.
What breaks in production
- No shaper, so the ISP's policer decides what to drop.
- Shaping at line rate, which leaves no queue to schedule.
- Uncapped priority queue, which starves all other classes.
- Trusting DSCP from client devices, letting a user mark bulk traffic as voice.
- QoS applied on the LAN while the WAN is the bottleneck.
- Testing at idle, when the problem only appears under load.
Checklist
- The shaper is set below the circuit rate.
- Priority traffic is capped, not unlimited.
- Bulk traffic has a guaranteed share, not zero.
- Client markings are not trusted at the edge.
- Measurements exist for voice quality under load.
- You know whether the ISP preserves DSCP.
Next
The edge is sized and shaped. The next series goes into the queue itself: QoS and Real-Time Traffic.