Explain the forwarding per-hop behavior (PHB) for QoS

Why QoS exists

A router or switch interface can only send one bit at a time. When more traffic arrives than a link can carry, packets wait in a queue; if the queue fills, packets are dropped. For a file download, a queued or dropped packet just means a slightly slower transfer, because TCP retransmits. For a phone call, a packet that arrives 300 ms late is useless and is thrown away, and a dropped packet is a click or gap in the audio.

Quality of Service (QoS) is the set of tools that lets you decide which traffic waits and which traffic gets dropped when a link is congested. It cannot create bandwidth; it manages how the bandwidth you have is shared.

Four characteristics of traffic matter:

• Bandwidth: how many bits per second a flow needs.
• Delay (latency): how long a packet takes to cross the network, one way.
• Jitter: variation in delay from packet to packet. Voice codecs assume a steady stream; jitter forces the receiver to buffer, which adds delay.
• Loss: the percentage of packets that never arrive.

Cisco’s rule-of-thumb targets for interactive voice and video:

These numbers are testable. Data applications tolerate far worse; a web page loading with 500 ms of delay is annoying but works.

Per-hop behavior

QoS in IP networks is per-hop behavior (PHB): each router or switch along the path independently looks at a marking in the packet header and decides how to queue, drop, or shape that packet. There is no end-to-end reservation (that was the idea behind an older model called IntServ with RSVP, which rarely gets deployed). The modern model is DiffServ (Differentiated Services): mark the packet once near the source, and every hop honors the mark. For this to work, every device must agree on what each mark means, which is why standard PHB values exist.

The QoS toolset, in the order packets meet it:

1. Classification: identify what kind of traffic a packet is.
2. Marking: write a value into the header so later hops do not have to re-classify.
3. Queuing (congestion management): when the link is busy, decide the order packets leave.
4. Congestion avoidance: drop selectively before queues overflow.
5. Policing and shaping: enforce a rate limit, by dropping or delaying.

4.7 Classification and marking

Classification means sorting packets into classes. A device can classify by almost anything: source or destination IP (via an ACL), TCP/UDP port (voice RTP uses UDP 16384 to 32767 on Cisco phones), incoming interface, or deep inspection of the application (Cisco NBAR, Network Based Application Recognition, can tell YouTube from Webex). Classification is expensive, so it should happen once, near the edge.

Marking records the result of classification in a header field so every later hop can classify with a single lookup. Two fields are used:

Class of Service (CoS) lives in the Layer 2 802.1Q trunk tag. It is a 3-bit field, so values are 0 to 7. Because it lives in the VLAN tag, it only exists on trunk links and is lost when the frame is routed (the router strips the Ethernet header). Cisco IP phones mark voice at CoS 5.

Differentiated Services Code Point (DSCP) lives in the Layer 3 IP header, in the 8-bit field originally called Type of Service (ToS) in IPv4 (Traffic Class in IPv6). DSCP uses the high 6 bits of that byte, giving values 0 to 63 (the low 2 bits are ECN, Explicit Congestion Notification). Because it is in the IP header, DSCP survives across routers end to end, making it the preferred marking.

An older scheme, IP Precedence (IPP), used only the top 3 bits of the ToS byte (values 0 to 7). DSCP is backward compatible: the Class Selector values below map to the same top 3 bits.

Standard DSCP values (PHBs)

Assured Forwarding defines four classes (x = 1 to 4, higher is better queue treatment) each with three drop precedences (y = 1 to 3, higher means more likely to be dropped during congestion). The decimal value is 8x + 2y:

For example, AF41 = 34 is the common marking for interactive video; AF31 = 26 for mission-critical data. Voice is EF = 46, which in binary is 101110; its top three bits (101 = 5) match CoS 5 and IP Precedence 5, which is why voice is “5” at Layer 2 and “46” at Layer 3.

Trust boundary

If any host could mark its own packets EF, a user could mark BitTorrent as voice and starve real calls. So the network defines a trust boundary: the point beyond which markings are believed. Markings arriving from outside the boundary are re-marked (usually to 0) or re-classified.

Typically the trust boundary is the access switch port. A Cisco IP phone is trusted (it marks its own voice EF/CoS 5 and, on its built-in switch port, re-marks the attached PC’s traffic to 0). A PC by itself is not trusted. On the switch, mls qos trust cos or mls qos trust dscp (or auto qos voip cisco-phone) sets what a port trusts; the phone itself is often the trust boundary, extended from the switch via CDP.

4.7 Queuing and congestion management

When packets arrive faster than the interface can send, they are held in output queues. Congestion management is choosing which queue sends next.

• FIFO (first in, first out): one queue, packets leave in arrival order. Simple, no differentiation. A burst of downloads delays voice.
• Weighted Fair Queuing (WFQ): flows are separated automatically; each gets a fair share weighted by its IP precedence. Automatic but not very controllable.
• Class-Based Weighted Fair Queuing (CBWFQ): you define classes (by DSCP, ACL, and so on) and give each a guaranteed minimum bandwidth (bandwidth in a policy-map). The scheduler visits queues round-robin in proportion to those weights. Good for data, but even a guaranteed class can still wait its turn, so voice can suffer jitter.
• Low Latency Queuing (LLQ): CBWFQ plus one priority queue (priority in a policy-map). Whenever the priority queue has a packet, it is sent next, ahead of everything else, up to a configured rate. Voice (EF) goes in the priority queue, so it experiences minimal delay and jitter. The rate cap (policing built into the priority queue) prevents a flood of voice from starving all data.

LLQ is the standard recommendation: voice in the priority queue, video and critical data in bandwidth-guaranteed CBWFQ classes, everything else in the default class.

A typical IOS policy for reference (built with the Modular QoS CLI, MQC):

R1(config)# class-map match-any VOICE
R1(config-cmap)# match dscp ef
R1(config-cmap)# exit
R1(config)# class-map match-any VIDEO
R1(config-cmap)# match dscp af41
R1(config-cmap)# exit
R1(config)# policy-map WAN-OUT
R1(config-pmap)# class VOICE
R1(config-pmap-c)# priority percent 20
R1(config-pmap-c)# class VIDEO
R1(config-pmap-c)# bandwidth percent 30
R1(config-pmap-c)# class class-default
R1(config-pmap-c)# fair-queue
R1(config-pmap-c)# exit
R1(config-pmap)# exit
R1(config)# interface GigabitEthernet0/1
R1(config-if)# service-policy output WAN-OUT

The exam does not require you to write this, but recognizing that priority = LLQ priority queue and bandwidth = CBWFQ guarantee helps.

4.7 Congestion avoidance: tail drop versus WRED

A queue has a finite length. When it is completely full, every new arrival is dropped: tail drop. Tail drop is bad for TCP in a specific way. Many TCP flows lose packets at the same instant, all of them slow down together, the link goes nearly idle, then they all speed up together and overflow the queue again. This sawtooth is called TCP global synchronization and wastes bandwidth.

Weighted Random Early Detection (WRED) avoids this by dropping a few packets at random as the queue grows past a minimum threshold, and dropping more aggressively as it approaches a maximum threshold. Random drops nudge different TCP flows to slow down at different times, keeping the queue partly full and the link busy. The “weighted” part means packets with a higher drop precedence (AF13 versus AF11) are dropped earlier and more often, which is exactly what the AF drop-precedence markings are for.

WRED is useful for TCP data. It should not be applied to the voice priority queue: voice is UDP, does not slow down when dropped, and every drop is audible.

4.7 Policing and shaping

Both tools limit traffic to a rate. The difference is what they do with the excess.

Example: a customer buys a 50 Mbps service delivered over a 1 Gbps Ethernet handoff. The ISP polices inbound traffic from the customer at 50 Mbps, dropping anything above. If the customer’s router just sends at line rate, the ISP drops a lot of packets. So the customer shapes outbound traffic to 50 Mbps: the router queues bursts and releases them at 50 Mbps, so nothing hits the policer. Shaping adds a little delay but avoids the drops.

Policers also support re-marking instead of dropping: traffic under the rate keeps its marking, traffic over the rate is re-marked to a higher drop precedence (say AF11 to AF13), and a downstream WRED policy drops it first only if congestion occurs.