Deciding Who Goes First

A network link is a shared resource, and when demand exceeds capacity something must wait or be dropped. Quality of Service (QoS) is the set of techniques for deciding which traffic gets priority, which gets delayed, and which gets discarded. It is how networks deliver acceptable voice and video alongside bulk downloads.

Why Not Just Add Bandwidth

Adding capacity helps until it doesn't: congestion happens in bursts, at bottlenecks, and across shared paths you do not control. QoS matters most where the link is constrained—a home uplink, a saturated WAN, or a peering point during peak hours. The goal is not to eliminate congestion but to control who experiences it.

The Traffic Management Toolkit

  • Classification: identify traffic types (by port, protocol, DSCP marking, or deep inspection).
  • Marking: tag packets (typically with DSCP bits) so downstream devices can make consistent decisions.
  • Queuing: separate traffic into queues with different priorities (priority, weighted-fair, class-based).
  • Shaping: smooth traffic to a target rate by buffering and delaying excess packets.
  • Policing: enforce a rate by dropping or re-marking excess packets.
  • Admission control: refuse new sessions when the network is already over capacity.

Priority vs. Fairness

Two principles shape design:

  • Priority queuing gives delay-sensitive traffic (VoIP, video conferencing) strict precedence with a low-latency queue. The risk is starvation: a flood of high-priority traffic can starve everything else.
  • Fair queuing (and its weighted variant) divides bandwidth among flows so no single flow monopolizes the link. This directly counters bufferbloat, where a large upload saturates a link and adds seconds of latency to every other flow.

Modern home routers and Linux's fq_codel/CAKE algorithms use fair queuing to keep latency low under load—often a bigger real-world win than raw bandwidth increases.

DiffServ vs. IntServ

The scalable model is Differentiated Services (DiffServ): mark classes at the edge, then give each class a forwarding treatment (per-hop behavior) everywhere else. It requires no per-flow state in the core. The older Integrated Services (IntServ) reserved resources per flow using RSVP—conceptually elegant but it does not scale to internet-sized traffic, so DiffServ won.

Where QoS Is Enforced

QoS only works where every device agrees on the markings and policies. Across the public internet you cannot control other operators' queues, so end-to-end guarantees are limited. This is why real-time applications use adaptive techniques—codecs that tolerate loss, jitter buffers, and adaptive bitrate—rather than relying on network guarantees. QoS is most effective inside networks you operate: enterprise WANs, data-center fabrics, and ISP backbones.

Practical Takeaways

  • Prioritize voice/video and interactive traffic; deprioritize bulk backups and updates.
  • Use fair queuing to fight bufferbloat; latency under load matters more than peak throughput.
  • Mark consistently so policies compose across devices.
  • Shape (delay) rather than police (drop) when you can, because dropping forces retransmissions.
  • Remember QoS cannot create capacity—only allocate scarcity more fairly.

Measuring the Effect

QoS tuning is only meaningful when you measure it. Track latency under load (not idle latency), jitter, packet loss, and the fill level of each queue. Tools like tc and codel statistics on Linux, active probing with ICMP or HTTP, and flow telemetry all reveal whether prioritization is producing the intended experience. The most common failure is marking traffic at the edge but forgetting to configure matching queues downstream, so the markings are ignored and every class is treated identically. Verify both ends of the path. When a network is well-tuned, the improvement is invisible to well-behaved traffic and obvious to the applications that depend on low latency—which is exactly the point.