1.4Interpreting QoS configurations

QoS is not a technology for adding bandwidth—it is a technology for deciding in advance what gets sacrificed at the moment bandwidth runs short. On an uncongested link, QoS configuration does almost nothing. What ENCOR asks is whether you can read a configuration of class-map, policy-map, and service-policy and explain how each kind of traffic is treated under congestion, and whether you can pinpoint which part of the configuration causes a given symptom (choppy voice, rising TCP retransmissions).

1.4.1Classification and marking

• Classification distinguishes traffic by criteria (ACLs, protocols, input interface, existing markings, and so on); in IOS you define the criteria with a class-map. As a principle, classify as close to the trust boundary and the source as possible—matching L4 criteria repeatedly in the core is inefficient.
• Marking writes the classification result into the packet/frame header. At L3 it uses DSCP in the IP header (6 bits, DiffServ); at L2 it uses CoS inside the 802.1Q tag (3 bits). Once marked, every subsequent hop can decide treatment just by reading the marking—this is the DiffServ philosophy of "classify and mark at the edge, trust the marking in the core." Representative values are EF (46) for voice, CS3 for signaling, and DF (0) for best effort.
• Designing the trust boundary is essential. Blindly trusting DSCP values set by user endpoints means anyone can mark their own traffic EF, rendering prioritization meaningless. The standard practice is therefore not to trust markings on access ports (or to trust them only from specific devices such as IP phones) and to re-mark values arriving from the untrusted side.

1.4.2Queuing

• Queuing matters only when the egress interface is congested. Without congestion, packets do not accumulate in queues and priority differences never appear. Many "we deployed QoS but nothing changed" reports come down to no congestion actually occurring, or the congestion being somewhere other than where the policy was applied.
• LLQ (Low Latency Queuing) adds a strict-priority queue to CBWFQ (weighted queuing that guarantees bandwidth per class). Delay-sensitive voice goes into the priority queue and is sent ahead of everything else. Crucially, the priority queue comes with a bandwidth cap (a policer); without it, voice could monopolize the link and starve the other classes. In IOS, priority specifies the priority queue and its bandwidth.
• Congestion avoidance is a separate concept: mechanisms such as WRED drop probabilistically before the queue fills, preventing TCP global synchronization (all flows backing off and ramping up together). With nothing in place, the queue overflows and drops uniformly from the tail—tail drop—sending many TCP flows into retransmission and congestion control simultaneously.

1.4.3Policing and shaping

• Policing discards excess above the contracted rate on the spot (or demotes its marking). Because nothing is buffered it does not add delay, but the excess is lost. Applied to TCP it triggers a drop, retransmit, shrink-the-congestion-window reaction, so throughput falls in steps. It can be applied on ingress too, making it suitable for limiting inbound traffic from others.
• Shaping buffers the excess and sends it later, smoothing output to the contracted rate. Since nothing is discarded it is less likely to induce TCP retransmissions, but it adds delay and jitter (more so with deeper buffers). It is applied on egress only as a rule. The classic use is throttling your own transmission to match a remote site's circuit speed—the well-known hub-and-spoke speed mismatch remedy.
• How to choose: delay-sensitive real-time traffic (voice/video) sits badly with shaping, which adds delay, so handle it with a priority queue plus a capping policer. Conversely, bulk transfers (backups, file sync) can tolerate delay, so smoothing them with shaping reduces retransmissions across the link. The order of reasoning is to decide from the requirement whether traffic may be dropped or may be delayed.

Suppose that on a 50 Mbps WAN link between headquarters and a branch you receive two reports at once: "voice breaks up during business hours" and "the nightly backup transfers slowly with abnormally high TCP retransmissions." The current configuration classifies voice by DSCP EF into an LLQ priority queue and lumps everything else under a policer capped at 40 Mbps. Checking show policy-map interface first, you find the priority queue's drop counter climbing during business hours. That means voice traffic is exceeding the bandwidth cap (policer) attached to the priority queue. The cap on a priority queue exists not to protect voice but to keep voice from starving everything else, so once concurrent calls exceed the assumption, the excess is dropped without mercy and shows up as exactly the choppiness reported. Removing the priority-queue cap here is dangerous: without it, voice can monopolize the link under congestion and stall all business traffic. The sound actions are to right-size the priority-queue bandwidth from measured concurrent-call counts and to revisit the trust boundary on access ports, verifying that non-voice traffic self-marking as EF has not slipped into the priority queue (the latter is detectable when the priority class's match count is disproportionate to the expected call volume). As for the nightly backup, the direct cause of the retransmissions is that the policer is discarding the excess. Because bulk transfer is TCP, drops immediately provoke retransmission and congestion-window shrinkage, so effective throughput falls in steps. A backup may be delayed but wastes effort when data is lost and resent, so the appropriate judgment is to replace policing with shaping, buffering the excess and absorbing it as delay. Deciding to "put the backup in the priority queue to speed it up" is a fundamental category error: the priority queue exists for delay-sensitive traffic, and putting bulk transfer in it directly worsens voice latency. Similarly, "upgrade the link to 100 Mbps" appears to work but leaves the essential design question of priority under congestion unresolved, so the same symptoms return as traffic grows. The standard method for QoS diagnosis is to determine whether a symptom is the result of being dropped or of being delayed, and to confirm it with per-class drop counters in show policy-map interface.

1.4.4Section summary

• QoS adds no bandwidth; it decides what gets sacrificed under congestion. The order is classification (class-map) then marking (DSCP/CoS) then queuing, and markings from outside the trust boundary are not trusted
• Voice goes to the LLQ priority queue marked DSCP EF (46). The priority queue comes with a bandwidth cap (a policer) that exists to prevent starving other classes and must not be removed
• Policing drops excess (no added delay but induces TCP retransmission) while shaping buffers it (fewer retransmissions but added delay/jitter, egress only). Decide from the requirement whether traffic may be dropped or delayed