QoS and Traffic Shaping: Prioritizing What Matters on the Network

Bandwidth does not fix latency

The reflexive answer to a slow network is to buy more bandwidth, and for bulk transfers it often helps. But the traffic that generates complaints — voice, video, interactive applications, trading and control signals — is rarely starved for throughput. It is starved for timely delivery. A congested link does not drop a voice packet because the pipe is full on average; it drops or delays it because a backup job filled the output queue for the 40 milliseconds that mattered. Quality of Service is the set of mechanisms that let a router or switch make that 40-millisecond decision in favor of the packet that cannot wait.

QoS does not create capacity. It allocates scarcity. On an uncongested link it does nothing, which is exactly right. Its entire job is to impose your priorities at the precise moments when not everything can go at once — and to do it consistently enough that the applications that matter stay usable while the ones that do not absorb the pain.

Classify and mark at the edge

Every QoS design begins with sorting traffic into classes, and the cardinal rule is to mark once, at the trust boundary, as close to the source as possible. The common marking lives in the IP header's DSCP field (Differentiated Services Code Point, the 6 bits repurposed from the old ToS byte). Standard code points map to per-hop behaviors:

• EF (Expedited Forwarding, DSCP 46) for real-time voice — low latency, low jitter, low loss.
• AF (Assured Forwarding) classes for interactive and business traffic that needs a guarantee but tolerates more delay than voice.
• CS (Class Selector) values for control-plane and signaling traffic.
• Default (DSCP 0) — best-effort — for everything else, including bulk and scavenger traffic.

Two disciplines make or break this. First, define a trust boundary: markings that arrive from untrusted devices (a user PC claiming EF for its game traffic) must be rewritten or ignored, while markings from trusted sources (the IP phone, the SBC) are honored. Second, keep the number of classes small. A four-to-six class model is enforceable and auditable; a twelve-class model is a spreadsheet nobody maintains. Marking is meaningless unless every hop in the path is configured to act on it, so QoS is an end-to-end policy, not a per-device knob.

Queues are where priority actually happens

Marking only labels traffic; queuing is what enforces the label when a link congests. When packets arrive faster than an interface can send them, they wait in queues, and the scheduling discipline decides who waits and who goes:

• Priority Queuing (PQ / LLQ). A strict low-latency queue is serviced before all others — correct for voice, dangerous if uncapped, because unbounded priority traffic can starve everything else. Always police the priority queue to a ceiling.
• Weighted fair / class-based weighted fair queuing. Each class gets a guaranteed share of the link proportional to its weight, so business traffic gets its minimum while bulk traffic gets the leftovers — and can borrow idle capacity.
• Active Queue Management. Schemes like WRED drop or mark packets before the queue is completely full, signaling TCP senders to slow down early and avoiding the global-synchronization and bufferbloat problems that come from letting deep buffers fill. Modern AQM such as CoDel targets queue delay directly rather than queue length.

The design pattern that works for most enterprises: one strict-priority queue for voice (capped), a handful of weighted classes for tiered business traffic, WRED on the TCP-heavy classes, and a bounded scavenger class for backups and updates.

Policing versus shaping: drop or delay

Two mechanisms enforce a rate, and confusing them causes real damage. Both cap traffic to a configured rate, but they handle the excess differently.

• Policing measures the rate and drops (or re-marks) anything over the ceiling immediately. It is cheap, requires no buffer, and is bursty and harsh — fine for enforcing a hard limit on scavenger traffic or a customer's contracted rate, but punishing for TCP, which reacts to the drops with sawtooth throughput.
• Shaping measures the rate and buffers the excess, releasing it smoothly up to the ceiling. It costs memory and adds a little latency, but it produces even flows and avoids needless retransmits.

The classic and essential use of shaping is the speed-mismatch handoff: a carrier hands you a 1 Gbps physical port but sells you a 200 Mbps committed rate. If you send at line rate, the carrier polices you and drops the overage — and drops it after your carefully prioritized QoS has already been applied, wrecking it. The fix is to shape your egress to the contracted rate on your own edge, so your queuing policy runs against the real bottleneck and your priorities survive the handoff.

QoS across the WAN and the internet

QoS is straightforward inside your own equipment and collapses the moment traffic leaves it. The public internet does not honor your DSCP markings; most providers bleach or ignore them, so there is no end-to-end guarantee across a commodity circuit. This is precisely the gap that changes the enterprise WAN calculus.

On private transport (MPLS) the carrier honors a contracted class model, which is part of what you pay the premium for. On the internet you get none of it — which is why an SD-WAN overlay approaches the problem differently. Rather than trusting the underlay to prioritize, it measures each path's loss, latency, and jitter continuously and steers application traffic onto whichever link is meeting the policy, failing over on brownout rather than only on outage. It can also apply per-application shaping and forward error correction to protect real-time flows across imperfect links. The result is application-aware priority without depending on the internet to cooperate. Getting the underlying class model right still matters; the SD-WAN documentation covers how policy maps to path selection.

Where to start

Do not deploy an elaborate class model on day one. Start by measuring — you cannot prioritize what you have not classified, so use flow and application visibility to learn what actually traverses your links and when they congest. Then:

1. Define a small class model (four to six classes) tied to real business priority.
2. Mark at the trusted edge and enforce a clear trust boundary.
3. Build queues with a capped priority class for voice and weighted classes beneath.
4. Shape egress to the real contracted rate at every speed-mismatch handoff.
5. Validate under load and during a genuine congestion event, not just on a quiet afternoon, using infrastructure monitoring to confirm the right traffic is winning.

QoS rewards restraint and punishes complexity. A simple policy that everyone understands and every hop enforces beats an intricate one that drifts out of sync. intSignal designs and validates QoS across LAN, WAN, and SD-WAN so the traffic that runs your business stays usable when the link fills up — talk to our team to build a policy that holds under pressure.