Quality of service: voice first when the link is busy
Lesson 2 of 4
2Quality of service: voice first when the link is busy
The big pictureA 2 GB file uploading two minutes earlier or later bothers nobody. But voice in a call that arrives 300 ms late makes conversation impossible, and 3% loss makes it choppy. On wide-area links between branches, where capacity is costly, QoS is what keeps the call clear while someone uploads a huge file.
What the picture shows: At the edge the kind of traffic is identified and written into the IP header; every router after that reads the mark and queues the packet, and voice always leaves first within a cap it cannot exceed.
Map of this part
The concepts in order, click any one to jump to it:
Two ways into the same idea
Picture a busy road by a hospital. The ambulance (voice) has its own lane and goes first, but its lane is narrow so it cannot take the whole road. Buses (video) get a guaranteed lane, and lorries (backups) take what is left. QoS is the traffic officer: it reads each vehicle's plate (the mark) and sends it to its lane. But remember: when the road is empty nobody needs the officer.
Voice targets: one-way delay ≤ 150 ms (ITU-T G.114), jitter ≤ 30 ms, loss ≤ 1%. DSCP is six bits in the IP header (RFC 2474): EF = 46 for voice (RFC 3246), AF41 = 34 for interactive video, CS6 = 48 for routing protocols, 0 for best effort. Trust boundary: trust the mark only from the official phone and re-mark everything else. LLQ: a strict priority queue for voice with a policer capping it (usually ≤ 33% of the link), and CBWFQ shares the rest. Policing drops the excess at once; shaping buffers and delays it to leave at a steady rate, used before a provider link slower than the port. A G.711 call needs about 87 kbps including Ethernet headers.
Before You Start
📦Transport: TCP and UDP
You know voice runs on UDP and is never resent.
📈Monitoring the network
You know dropped packets and latency.
The Core Idea
1When do you need QoS at all?
QoS works only under congestion: when more packets arrive than can leave, so they queue. On a 10 Gbps LAN with few users it barely shows. Its real home is WAN links between branches, the internet uplink, Wi-Fi, and points where many ports funnel into one. The first question is always: can I fix this with more capacity at a fair price?
| Traffic | Delay | Jitter | Loss | DSCP |
|---|---|---|---|---|
| Voice | ≤ 150 ms one way | ≤ 30 ms | ≤ 1% | EF (46) |
| Interactive video | ≤ 200 ms | ≤ 30–50 ms | ≤ 0.1–1% | AF41 (34) |
| Business apps | Flexible | Not critical | TCP resends | AF21 (18) |
| Backups and updates | Does not matter | Does not matter | TCP resends | CS1 (8) |
2Classifying and marking with DSCP
Classify as close to the source as you can: the phone port, or a list matching ports and addresses. Then mark the packet by writing a DSCP value into the IP header, so no router after that needs to look again. The trust boundary matters: trust any mark and every program will mark its traffic EF to jump the queue.
This is what you see in Wireshark: the ToS field is one byte and its top six bits are the DSCP.
CLASSES = {46: "EF voice", 34: "AF41 video", 26: "AF31 signalling", 18: "AF21 business",
8: "CS1 scavenger", 48: "CS6 routing", 0: "best effort"}
def dscp_of(tos_byte):
return tos_byte >> 2 # DSCP is the top 6 bits of the old ToS byte
for tos in (0xB8, 0x88, 0x00, 0x20, 0xC0):
d = dscp_of(tos)
print(f"ToS 0x{tos:02X} = {tos:08b} -> DSCP {d:2} ({d:06b}) {CLASSES.get(d, '?')}")3Queues: priority and shares
An outbound port has several queues. LLQ is a strict priority queue: whenever a voice packet waits, it goes first. But it is capped, or too much voice would starve everything else. The rest sit in CBWFQ: each class gets a guaranteed share under congestion, and spare capacity is shared. In the best-effort queue, WRED drops a few TCP packets a little early before the queue fills, so senders slow down before everything is dropped.
class-map match-any VOICE match dscp ef policy-map WAN-OUT class VOICE priority percent 30 ! LLQ, capped at 30% class VIDEO bandwidth percent 25 class class-default fair-queue random-detect dscp-based ! shape to the provider rate, then queue inside the shaper policy-map SHAPE-50M class class-default shape average 50000000 service-policy WAN-OUT interface gi0/0/1 service-policy output SHAPE-50M
4Policing, shaping and sizing voice
Your port runs at 1 Gbps but the provider contract is 50 Mbps. Send faster and the provider drops the excess at random (policing), taking your voice with it. The fix is to shape to 50 Mbps yourself before leaving, so the queue forms on your side where your QoS works. To size the voice queue, multiply simultaneous calls by the bandwidth of one call.
Change the number of calls or the codec to see when voice passes a third of the link.
def call_kbps(codec_kbps, ms_per_packet, overhead_bytes):
pps = 1000 / ms_per_packet
payload = codec_kbps * 1000 / 8 / pps # bytes of voice per packet
return (payload + overhead_bytes) * 8 * pps / 1000
ETH_IP_UDP_RTP = 18 + 20 + 8 + 12 # Ethernet + IP + UDP + RTP headers
g711 = call_kbps(64, 20, ETH_IP_UDP_RTP)
g729 = call_kbps(8, 20, ETH_IP_UDP_RTP)
print(f"G.711 call: {g711:.1f} kbps G.729 call: {g729:.1f} kbps")
link_mbps, calls = 50, 120
need = calls * g711 / 1000
print(f"{calls} G.711 calls need {need:.1f} Mbps = {100 * need / link_mbps:.0f}% of {link_mbps} Mbps")
print("fits a 33% priority queue" if need <= link_mbps * 0.33 else "too much voice: use G.729 or a bigger link")Worked example
The task: a branch on a 20 Mbps WAN link with 40 phones (at most 25 simultaneous G.711 calls), meeting video, and a nightly backup that sometimes starts in the day. Calls break up during backups. Design the policy.
The answer: voice: 25 × 87.2 ≈ 2.2 Mbps, about 11% of the link, so a priority queue capped at 15% fits with headroom. Video AF41 with a 30% share. Business apps AF21 with 20%. The backup is marked CS1 and gets only what is left. Trust boundary: phone ports trust the phone's mark, every other port is re-marked 0. Most important: shape to 20 Mbps on the outbound port and nest the policy inside the shaper. Verify by measuring call jitter and loss during a test backup.
Myth vs Reality
| Myth | Reality |
|---|---|
| QoS makes the link faster. | It adds not a single bit. It only decides who is dropped or waits when it is full. |
| Make everything important high priority. | If everything is priority, nothing is. The strict queue is for voice only, and capped. |
| Marks cross the internet intact. | The public internet usually ignores your marks. QoS works on networks you control or under a provider contract. |
Where you meet it at work
📞IP telephony
An EF queue keeps calls clear despite congestion.
🏥Hospitals
Patient monitors get a protected class on the wireless network.
🏪Branches and shops
Point-of-sale traffic beats system updates on a small link.
Test your understanding
What is the usual DSCP value for voice?
Expedited Forwarding for voice, AF41 for video.
What is the recommended maximum one-way delay for voice?
The ITU-T G.114 guidance for natural conversation.
What is the difference between policing and shaping?
That is why you shape before the provider link instead of being policed by it.
Why is the voice priority queue capped?
A strict queue with no cap takes the whole link if it fills.
Where do you put the trust boundary?
The point nearest the source where you can verify the device is an official phone.
Quick review cards
Check Your Understanding
Why do you rarely need QoS on a 10 Gbps LAN?
Because queues form only under congestion, which is rare at that capacity.
A call breaks up although voice is marked EF. What do you check first?
Is the queue forming where your policy lives? If congestion is at the provider with no shaping on your side, your policy never acts.
Why mark backups CS1 instead of leaving them best effort?
So it gets less than normal traffic and does not crowd out even browsing under congestion.
Resources for this lesson
Grouped by type. Start with the official docs for precision, or an article or video for the explanation.
Done with this lesson?
Sign in to save your progress.