1.3 Quality of Service (QoS) Architecture, Classification, Queuing, and Configuration Interpretation

Quality of Service (QoS) Architecture, Classification, Queuing, and Configuration Interpretation

Quality of Service (QoS) provides predictable, deterministic network behavior for latency-sensitive applications—such as real-time voice, interactive video, and business-critical transactions—competing against bulk data across constrained enterprise campus links.

---

Fundamental QoS Models

Modern enterprise networks implement one of three standard QoS models:

1. Best Effort: The default operational model. Packets receive First-In, First-Out (FIFO) scheduling without classification, resource reservation, or preferential treatment. When links become congested, packets are dropped indiscriminately.
2. Integrated Services (IntServ / RSVP - RFC 1633 / RFC 2205): A "hard QoS" model where endpoints signal their bandwidth and latency requirements end-to-end using the Resource Reservation Protocol (RSVP). Every intermediate router along the path must maintain per-flow state tables and reserve explicit bandwidth before traffic flows. While IntServ guarantees QoS, it fails to scale in large enterprise networks because tracking thousands of individual microflows exhausts router memory and CPU resources.
3. Differentiated Services (DiffServ - RFC 2474): A "soft QoS" model that replaces per-flow state with scalable class-based aggregation. Ingress edge devices classify and mark packets into aggregated traffic classes. Intermediate nodes inspect these markings and apply stateless Per-Hop Behaviors (PHB)—such as specific queuing, scheduling, and drop mechanisms. DiffServ scales seamlessly and serves as the foundation for modern enterprise network QoS.

---

Classification and Marking: Layer 2 CoS vs. Layer 3 DSCP

Classification identifies traffic flows; marking alters a designated header field to categorize packets for subsequent queuing treatment.

Layer 2 Class of Service (CoS)

In 802.1Q tagged Ethernet frames, the 16-bit Tag Control Information (TCI) field includes the 3-bit Priority Code Point (PCP), which carries the Class of Service (CoS) value (0–7). Because CoS resides within the Layer 2 802.1Q header, it is lost whenever a frame crosses a Layer 3 routed boundary or traverses an untagged access port.

Layer 3 Differentiated Services Code Point (DSCP)

RFC 2474 redefined the legacy 8-bit IPv4 Type of Service (ToS) byte and IPv6 Traffic Class byte:

• DSCP Field (Bits 0–5): The first 6 bits define the Differentiated Services Code Point (DSCP), providing 64 distinct codepoints (0–63).
• ECN Field (Bits 6–7): The last 2 bits are allocated for Explicit Congestion Notification (RFC 3168).

 0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---+
|       DSCP (6 bits)   |  ECN  |
+---+---+---+---+---+---+---+---+

DiffServ Architectural Classes

1. Default Forwarding (DF): DSCP 0 (000000), representing best-effort traffic.
2. Class Selector (CS): CS0 through CS7 provide backward compatibility with the legacy 3-bit IP Precedence (IPP) field. The decimal value equals IPP multiplied by 8:
   • CS1 = 8 (001000), CS2 = 16 (010000), CS3 = 24 (011000), CS4 = 32 (100000), CS5 = 40 (101000), CS6 = 48 (110000), CS7 = 56 (111000).
   • RFC 4594 recommends CS6 for network control traffic such as routing protocols; CS7 is reserved for future use.
3. Assured Forwarding (AF - RFC 2597): Defines four distinct classes (1 to 4) with three drop precedence levels per class (1 = Low, 2 = Medium, 3 = High). Formatted as AFxy where x is class (1–4) and y is drop precedence (1–3).
   • Decimal formula: DSCP = 8x + 2y
   • Example: AF31 has a decimal value of 8(3) + 2(1) = 26. AF32 has a value of 8(3) + 2(2) = 28. AF33 has a value of 8(3) + 2(3) = 30. Under congestion, AF33 is dropped before AF32, which is dropped before AF31.
4. Expedited Forwarding (EF - RFC 3246): DSCP 46 (101110). Designed for low-loss, low-latency, low-jitter real-time traffic, specifically VoIP media (Real-time Transport Protocol - RTP).

Standard DSCP Values and Enterprise Workloads

---

Trust Boundaries

A trust boundary establishes the physical perimeter where incoming QoS markings are accepted. Markings received from outside the trust boundary are untrusted and reset to best effort (DSCP 0).

• Untrusted Endpoints: Workstations, laptops, and printers often generate arbitrary markings. If left untrusted, rogue applications could mark peer-to-peer downloads as Expedited Forwarding (DSCP 46).
• IP Phone Demarcation: In enterprise deployments, an IP phone typically connects to a switch access port while a workstation daisy-chains into the PC port on the back of the phone. Using Cisco Discovery Protocol (CDP) or LLDP-MED, the switch establishes a conditional trust boundary:
  • Voice media from the phone (DSCP 46 / CoS 5) and signaling (DSCP 24 / CoS 3) are trusted.
  • Frames arriving from the downstream workstation are untrusted; their CoS and DSCP markings are rewritten to 0 at ingress.

---

Traffic Conditioning: Policing vs. Shaping

When traffic exceeds its contracted Committed Information Rate (CIR), traffic conditioning engines intervene:

Traffic Burst > CIR
        |
        +---> [POLICING] ---> Drop excess or Re-mark to lower DSCP (No Buffering, Ingress/Egress)
        |
        +---> [SHAPING]  ---> Buffer excess in memory, smooth output rate (Buffering delay, Egress only)

• Traffic Policing: Evaluates packets against a token bucket algorithm. Packets exceeding the CIR are immediately dropped or re-marked to a higher drop precedence (e.g., Markdown from AF21 to AF22). Policing introduces no delay or jitter because it does not buffer packets. However, dropping packets triggers TCP sliding window collapse. Policing is supported on both ingress and egress interfaces.
• Traffic Shaping: Enforces rate limits by holding excess packets in a software buffer queue, transmitting them at a steady, metered pace. Shaping smooths bursty transmission and prevents packet loss at the cost of introduced buffering delay and jitter. Because packets cannot be delayed before they arrive, shaping is supported only on egress (outbound) interfaces.

---

Congestion Management and Queuing

When an egress interface experiences congestion, hardware scheduling algorithms determine which packets are transmitted first:

1. Priority Queuing (PQ): Strict priority scheduling. Packets in the priority queue are always serviced before any lower queue. Without strict policing, high-volume priority traffic will completely starve non-priority queues.
2. Class-Based Weighted Fair Queuing (CBWFQ): Allocates guaranteed minimum bandwidth percentages to distinct traffic classes. During congestion, each class receives its configured bandwidth slice; remaining bandwidth is shared proportionally.
3. Low Latency Queuing (LLQ): Combines CBWFQ with a strict Priority Queue (PQ) for delay-sensitive traffic (voice and interactive video). Crucially, the PQ in LLQ is bounded by a strict policer. If voice traffic exceeds its provisioned rate, excess voice packets are dropped rather than allowing the priority queue to starve the CBWFQ data queues.

---

Congestion Avoidance: Tail Drop vs. WRED

When egress queues fill completely, the switch performs Tail Drop, discarding all subsequent incoming packets regardless of priority. In TCP-heavy networks, tail drop causes TCP Global Synchronization: dozens of concurrent TCP sessions experience simultaneous packet loss, drop their congestion windows simultaneously, and retransmit at the same time, producing severe throughput oscillations.

Weighted Random Early Detection (WRED) eliminates global synchronization:

• WRED monitors average queue depth. When queue occupancy crosses a minimum threshold, WRED begins probabilistically dropping packets at random before the buffer fills.
• By dropping individual packets from separate flows, TCP endpoints back off at staggered times.
• "Weighted" WRED uses IP Precedence or DSCP drop precedence values: packets marked with high drop precedence (such as AF23) begin dropping at lower queue thresholds than packets marked with low drop precedence (such as AF21).

---

Cisco MQC Configuration and Interpretation

The Modular QoS CLI (MQC) organizes QoS implementation into three decoupled steps:

1. class-map     --> Classifies traffic using match criteria
2. policy-map    --> Defines actions (priority, bandwidth, shape, police, set)
3. service-policy--> Applies policy-map to interface (input or output)

MQC Configuration Example

! Step 1: Classification
class-map match-all CM-VOICE-RTP
 match dscp ef

class-map match-all CM-MISSION-CRITICAL
 match dscp af31 af32

! Step 2: Policy Mapping
policy-map PM-CAMPUS-EGRESS
 class CM-VOICE-RTP
  priority level 1
  police cir 512000 conform-action transmit exceed-action drop
 class CM-MISSION-CRITICAL
  bandwidth percent 35
  random-detect dscp-based
 class class-default
  bandwidth percent 25
  fair-queue

! Step 3: Interface Application
interface GigabitEthernet1/0/1
 service-policy output PM-CAMPUS-EGRESS

Interpreting show policy-map interface

The show policy-map interface command provides critical operational verification:

Switch# show policy-map interface GigabitEthernet1/0/1
 GigabitEthernet1/0/1 

  Service-policy output: PM-CAMPUS-EGRESS

    Class-map: CM-VOICE-RTP (match-all)
      128492 packets, 20558720 bytes
      5 minute offered rate 124000 bps, drop rate 0000 bps
      Match: dscp ef (46)
      Priority: Strict Priority,
      police:
        cir 512000 bps, bc 16000 bytes
        conformed 128492 pkts, 20558720 bytes; actions:
          transmit
        exceeded 0 pkts, 0 bytes; actions:
          drop
        conformed 124000 bps, exceeded 0000 bps

    Class-map: CM-MISSION-CRITICAL (match-all)
      892100 packets, 1141888000 bytes
      5 minute offered rate 2850000 bps, drop rate 0000 bps
      Match: dscp af31 (26) af32 (28)
      Queueing
      queue limit 64 packets
      (queue depth/total drops/no-buffer drops) 0/0/0
      bandwidth 35% (350000 kbps)
      dscp-based WRED:
        dscp 26: min-threshold 40, max-threshold 60, mark-probability 1/10 (0 drops)
        dscp 28: min-threshold 30, max-threshold 50, mark-probability 1/10 (0 drops)

    Class-map: class-default (match-any)
      4521098 packets, 5786905440 bytes
      5 minute offered rate 14200000 bps, drop rate 1420 pkts
      bandwidth 25% (250000 kbps)

• Offered Rate vs. Drop Rate: Confirms incoming volume and drops. drop rate 0000 bps in the voice class indicates no voice packets are being discarded.
• Priority Policer Verification: The conformed counter records passed voice packets, while exceeded 0 pkts verifies that the 512 kbps strict priority policer has not discarded excess voice traffic.
• Queue Depth & WRED Drops: In CM-MISSION-CRITICAL, WRED monitors thresholds (e.g., dropping DSCP 28 at a minimum threshold of 30 packets versus DSCP 26 at 40 packets), successfully avoiding tail drops.

MQC Command Structure Breakdown