Two ways to ask the network for a favor
You have now met every tool an end host can use on its own: the playout buffer that absorbs jitter, RTP and SIP that package and set up a call, and the router machinery — scheduling and policing — from guide 4. But all of that is still riding on a network that treats every packet alike. The deeper question of this rung was whether we can ask the network itself to play favorites, and there turn out to be exactly two grand ways to ask. Both go by the umbrella name quality of service (QoS), and the whole drama of this guide is that the more ambitious one lost.
The first way is to make a firm promise to one flow at a time: before your call begins, walk the whole path, ask every router to set aside a guaranteed slice of itself for you, and only start once everyone says yes. That is Integrated Services (IntServ) — think of it as booking a private lane, end to end, for the duration of one call. The second way refuses to make per-call promises at all: stamp each packet with a small class tag at the network's edge, and have routers give whole classes of traffic rough preferential handling, with no idea which individual flow any packet belongs to. That is Differentiated Services (DiffServ) — think of it as painting a fast lane on the road and letting anything wearing the right sticker use it.
IntServ: a private lane reserved end to end
IntServ takes the timing problem seriously and tries to solve it properly: if a flow needs, say, a steady 100 kbps with bounded delay, then every router along its path should actually commit that much to it. To set this up, the sender's call uses a signaling protocol (the classic one is RSVP) to send a reservation request hop by hop toward the receiver. Each router checks: do I still have enough spare capacity to honor this on top of everything I have already promised? This check is called admission control — the network can say no, exactly like a fully booked restaurant turning you away at the door rather than seating you and ruining everyone's meal.
- The caller describes its flow: how bursty it is (often as a token bucket rate and burst size) and what guarantee it wants — a hard bandwidth-and-delay bound, or a looser "controlled load."
- A reservation request travels hop by hop along the path toward the receiver, visiting every router in between.
- Each router runs admission control: if it has enough uncommitted capacity, it reserves the slice and forwards the request; if not, it rejects the whole call.
- If every router along the path says yes, the reservation is confirmed end to end and the media starts flowing inside its guaranteed lane.
- While the flow runs, each router enforces the promise with a scheduler such as weighted fair queuing and tears the reservation down when the call ends.
On paper this is wonderful: a genuine, enforceable guarantee, the closest the Internet ever came to the old telephone network's reserved circuits. And that is exactly its undoing. A backbone router on a busy link may carry hundreds of thousands or millions of simultaneous flows, and IntServ asks it to remember per-flow state for every one — the reservation, the token-bucket parameters, a queue — and to consult all of that on every single packet. That is called per-flow state, and it is the heaviest thing you can ask a fast router to keep. Worse, the reservation has to hold across every independent network the path crosses; one router that does not speak RSVP, or one autonomous system that refuses to honor a stranger's reservation, and the guarantee silently evaporates.
DiffServ: stickers, not reservations
DiffServ was designed by people who had watched IntServ choke on its own bookkeeping, and its central move is to push all the hard, per-flow work to the edge and keep the core dumb and fast. Every IP packet already carries a small field in its header (the DS field, repurposed from the old type-of-service byte) into which the edge can write a class tag — a DSCP value. A handful of routers at the boundary of a network do the expensive part: they classify packets (is this voice? video? bulk download?), police them against an agreed rate, and stamp the right class onto each one. After that the tag is all that travels.
Deep in the core, a router does something refreshingly simple. It does not know or care which flow a packet belongs to; it just reads the class tag and applies a pre-agreed forwarding behavior — a per-hop behavior, in the jargon. Voice-marked packets might go into a low-latency priority queue; "assured" business traffic into a weighted fair queuing class with a generous share; everything else into ordinary best-effort. The router keeps state per class — maybe four or eight buckets — not per flow. That is the entire trick, and it is what lets DiffServ run at backbone speed where IntServ cannot.
IntServ (per-FLOW state, set up before the call)
sender --RSVP reserve--> R1 --> R2 --> R3 --> receiver
each router stores: this flow -> {rate, delay bound, queue}
millions of flows => millions of entries per router (does not scale)
DiffServ (per-CLASS state, decided once at the edge)
edge router: classify + police + stamp DSCP tag onto each packet
core router: read tag -> apply per-hop behavior
EF (voice) -> priority queue, low delay
AF (business) -> weighted-fair share
BE (default) -> plain best-effort
a handful of classes => a handful of entries per router (scales)DiffServ scales — but it does not promise
Here is the catch, and it is the honest heart of the comparison. A DiffServ class tag is not a reservation; it is only a relative preference. Your voice packets are handled before bulk downloads, yes — but if a hundred thousand other people also mark their packets as voice at the same instant, the priority queue itself overflows and your low-latency class suffers right along with everyone else's. DiffServ gives no per-flow bandwidth or delay bound the way IntServ does. It improves your odds; it does not write you a contract. Making even the relative promise stick across networks requires service-level agreements and policing at every boundary, which is exactly why DiffServ tends to work cleanly inside one operator's network and fray at the seams between operators.
So neither architecture is a clean winner on its own terms. IntServ offers real guarantees but cannot scale to the public Internet's millions of flows and crosses ownership boundaries badly. DiffServ scales beautifully but offers only soft, relative preference and still needs business agreements to mean anything beyond a single network. Both designs are real, deployed technology — DiffServ in particular is alive and well inside enterprise networks, mobile carrier cores, and datacenters, where one administrator controls every router and can make the markings mean something. What neither one became is the default fabric of the open Internet between strangers.
Why best-effort usually wins
Step back and the real outcome comes into focus: across the public Internet, most traffic still travels best-effort — every packet treated the same, no promises, exactly as it did before anyone dreamed up QoS. This is not because the engineers failed. It is because three quieter forces kept making the fancy guarantees not worth the trouble. The first is the end-to-end principle you met in foundations: keep the network core simple and dumb, push intelligence to the edges. Per-flow reservations in the core violate that principle directly, and the Internet's whole scaling story is a long vindication of keeping the middle stupid.
The second force is that the end hosts simply got too good at coping. Everything earlier in this rung is an end-host trick that needs zero help from the network: a generous playout buffer swallows jitter, loss concealment hides a missing audio frame, and adaptive bitrate streaming watches the connection and quietly drops to a lower video quality the moment the network tightens, then climbs back when it loosens. When the edges can gracefully ride out a rough patch on their own, the case for re-engineering the core to prevent rough patches grows thin.
The third force is the bluntest: bandwidth got cheap, so the simplest fix of all — just add more capacity, a strategy nicknamed overprovisioning — usually beats clever scheduling on cost and effort. A link that is rarely more than half full has tiny queuing delay and almost no loss for everyone, no markings required. QoS earns its keep precisely where you cannot just throw bandwidth at the problem: a congested cellular link, an oversubscribed datacenter fabric, a satellite hop, an enterprise WAN under one owner. That is the honest verdict of this whole rung. The mechanisms are real and they matter inside controlled networks, but on the open Internet between strangers, smart edges plus cheap, fat links keep letting plain best-effort win.