QoS (Quality of Service)
The congestion control article already showed what a saturated link looks like from the inside: bulk file transfers keep the network genuinely busy while a ping running alongside stays fast, because a small ICMP packet is cheap for a router to slip through even when its buffers for bulk data are backed up. That observation — that not all traffic has to wait its turn equally — is QoS in miniature. Left to itself, a router forwards whatever arrives in roughly the order it arrives; QoS is the deliberate decision to stop doing that, and to serve some traffic ahead of other traffic on purpose.
Why "just add more bandwidth" doesn't fully solve it
The obvious fix for a congested link is more capacity, and it genuinely helps — but it doesn't eliminate the underlying problem, because demand tends to expand to use whatever capacity is available. A video call and a large backup job competing for the same link will both suffer if the link is saturated, no matter how much total bandwidth exists, during the specific moments both happen to be transferring heavily at once. And some traffic isn't sensitive to available bandwidth at all — it's sensitive to consistency. A voice call doesn't need a huge amount of bandwidth; it needs every packet to arrive within a narrow, predictable window, and a backup job that occasionally bursts and fills the router's buffer for a fraction of a second can introduce exactly the kind of momentary delay that makes a voice call stutter, even on a link with plenty of average capacity to spare.
That's the actual problem QoS solves: not "not enough bandwidth" but "traffic with genuinely different requirements sharing one link, where the requirements conflict during moments of contention."
Latency, jitter, and packet loss are three different complaints
Different applications care about different things going wrong, and it's worth naming them separately because the fix for one doesn't necessarily fix another:
- Latency is how long a single packet takes to arrive. A file download tolerates high latency fine — nobody notices if the first byte takes an extra 50 milliseconds, as long as the bulk transfer completes reasonably.
- Jitter is variation in that latency from one packet to the next. A voice or video call is far more sensitive to jitter than to latency itself — audio arriving with a steady 100ms delay sounds fine once buffered appropriately; audio arriving at 50ms, then 300ms, then 80ms produces the stutter and garbling anyone who's used a bad VoIP connection recognizes instantly.
- Packet loss is a packet that never arrives at all. A file transfer over TCP recovers from loss transparently through retransmission, at some cost to throughput. A live voice or video stream, typically running over UDP for exactly the reasons the TCP vs UDP comparison already covered, usually has no such retransmission — a lost packet is a lost fraction of a second of audio, gone.
QoS exists to give the traffic that's sensitive to jitter and loss — voice, video, real-time control traffic — priority treatment during contention, while bulk transfers that only care about eventual completion wait a little longer without anyone noticing.
How a router decides what to prioritize
A router can't guess what a packet is for just by looking at it — it needs the packet to say so. That's the job of the DSCP (Differentiated Services Code Point), six bits inside the IP header's Type of Service field, standardized by RFC 2474, that mark a packet with its traffic class before it ever reaches a router capable of acting on that marking.
IPv4 header, byte 1 (the old "Type of Service" byte):
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| DSCP (6 bits) | ECN (2 bits) |
+-----+-----+-----+-----+-----+-----+-----+-----+
RFC 4594 defines a standard set of named classes built on top of that field, each mapped to a recommended DSCP value and a typical use case:
| Class | DSCP value | Typical traffic |
|---|---|---|
| EF (Expedited Forwarding) | 101110 |
VoIP, real-time voice — minimum jitter and loss |
| AF41 (Assured Forwarding) | 100010 |
Interactive video conferencing |
| Default (Best Effort) | 000000 |
Ordinary traffic with no special handling |
A packet marked EF isn't guaranteed to arrive faster in some absolute sense — DSCP is only meaningful to a router configured to read and act on it. What it does is tell every QoS-aware device along the path "treat this packet's jitter and loss sensitivity as a priority relative to everything else competing for the same queue," and a properly configured router honors that by serving EF-marked packets out of its queue ahead of best-effort traffic during contention.
qdisc htb 1: root refcnt 2 default 30
qdisc sfq 10: parent 1:10 limit 127p quantum 1514b
qdisc sfq 20: parent 1:20 limit 127p quantum 1514b
On Linux, tc (traffic control) is the tool that actually implements queuing policy based on markings like this — htb (Hierarchy Token Bucket) here is splitting outbound traffic into classes with different guaranteed rates, and packets get sorted into one queue or another based on criteria that commonly include the DSCP marking. Reading tc output in full detail belongs to the traffic-shaping article later in this course; the point here is only that DSCP marking and queue-based prioritization are two separate steps — marking says what a packet is, and a queuing policy is what actually decides who goes first.
QoS only matters where contention actually happens
Marking a packet doesn't guarantee anything by itself
A DSCP marking is only honored by devices configured to read it, and it can be stripped or ignored anywhere along the path — many ISPs and public internet routers reset or ignore DSCP markings on traffic crossing their network entirely, since honoring an arbitrary customer's own priority marking would let anyone claim their own traffic deserves priority. QoS marking is reliably effective on a network you control end to end — a corporate LAN, a data center, a managed WAN link — and generally not effective at all once traffic leaves onto the open internet, where no single administrator can enforce it.
This is why QoS matters enormously for a corporate office's internal network — where IT genuinely controls every router between the video conferencing system and the internet edge — and matters far less for, say, a home Wi-Fi router deciding how to prioritize a Netflix stream against a torrent download, since congestion there is much more likely to be occurring on the shared upstream ISP link the home router doesn't control at all. Consumer routers do sometimes implement basic local QoS specifically for this last case — recognizing and prioritizing latency-sensitive local traffic on the home network's own Wi-Fi and LAN segment — but that only helps for congestion happening on the home network itself, not for congestion further out on the ISP's shared infrastructure.
Practical scenario: video calls that stutter only when someone starts a backup
An office notices video calls degrade noticeably every weekday around 2 PM, with audio cutting in and out and video freezing periodically, then returning to normal an hour later. The pattern is too regular to be a coincidence.
qdisc htb 1: root refcnt 2 default 30
Sent 128934021 bytes 98234 pkt (dropped 1847, overlimits 3402 requeues 0)
The dropped 1847 figure, checked again after the next occurrence, climbs sharply during the exact window the complaints cover. Cross-referencing with the backup schedule finds the answer immediately: a scheduled cloud backup job kicks off automatically at 2 PM every weekday, saturating the office's uplink for roughly an hour while it uploads. With no QoS policy in place, the router treats the backup's bulk upload traffic and the video call's real-time traffic identically — both compete for the same outbound queue, and whichever happens to be waiting when the link is saturated gets delayed or dropped without distinction, which for a voice or video stream shows up immediately as stutter and freezing.
The fix is exactly the mechanism this article described: marking the video conferencing traffic with a high-priority DSCP value like EF, and configuring the router's queuing policy to genuinely serve EF-marked packets ahead of the backup job's best-effort traffic whenever both are competing for the same link — not eliminating the backup's bandwidth use, but making sure its bulk, loss-tolerant traffic yields to the smaller amount of jitter-sensitive traffic during contention. A second, entirely reasonable fix alongside it: simply moving the backup schedule outside business hours, since QoS is for genuine unavoidable contention, not a substitute for avoiding contention that's easy to avoid.
Practice exercises
- Explain, in your own words, why a file download over TCP is more tolerant of packet loss than a live voice call over UDP — and connect the answer back to what the TCP vs UDP comparison already covered about retransmission.
- A DSCP-marked packet leaves a company's own network and crosses three different ISPs before reaching its destination. Explain why the marking is likely to have no effect once it leaves the company's own infrastructure.
- Given the
tc -s qdisc showoutput pattern in the scenario above, describe what a risingdroppedcounter, specifically during a known period of contention, tells you that a steady baseline ofoverlimitsalone would not.
Every mechanism in this article assumed traffic was already flowing over the same shared infrastructure that's had to grow for decades to keep pace with demand — a growth that eventually ran headfirst into a hard numerical ceiling. That ceiling, and the transition already well underway to get past it, is where this module ends.