13.2 Queuing Algorithms and Congestion Management

Queuing Algorithms and Congestion Management

Quick Summary: In campus switching architectures, congestion occurs when the aggregate volume of ingress traffic directed toward an egress interface exceeds the physical transmission speed of that link (such as multiple 10 Gbps access uplinks converging onto a 10 Gbps aggregation port, or a 10 Gbps server port forwarding traffic toward 1 Gbps edge clients). To prevent indiscriminate packet drops during bursts, switches place packets into hardware egress queues. How these queues are serviced and emptied onto the physical medium is governed by queuing and scheduling algorithms (such as Strict Priority and Deficit Weighted Round Robin) paired with proactive congestion avoidance mechanisms (such as WRED).

---

AOS-CX Hardware Egress Queuing Architecture

Aruba AOS-CX switches feature dedicated ASIC packet buffers and hardware egress queues. The CX 6200 and 6300 provide 8 queues per port (Queue 0 through Queue 7); the CX 6400 provides 4 (AOS-CX 10.14 QoS Guide).

+-------------------------------------------------------------------------+
|               AOS-CX EGRESS QUEUING & SCHEDULING PIPELINE               |
|                                                                         |
| Ingress Packet -> QoS Trust/Map -> Local Priority (0-7)                |
|                                          |                              |
|                                          v                              |
|              +---------------------------------------+                  |
|              | Queue 7: Voice RTP      (Strict Pri)  |======> [EGRESS]  |
|              +---------------------------------------+        |         |
|              | Queue 6: Video Conf     (DWRR: 30%)   |        |         |
|              +---------------------------------------+        |         |
|              | Queue 5: Signaling/Call (DWRR: 20%)   |        |         |
|              +---------------------------------------+        |         |
|              | Queue 4: Critical Data  (DWRR: 20%)   |======> [PORT]    |
|              +---------------------------------------+        |         |
|              | Queue 3: Standard Data  (DWRR: 15%)   |        |         |
|              +---------------------------------------+        |         |
|              | Queue 2: Background     (DWRR: 10%)   |        |         |
|              +---------------------------------------+        |         |
|              | Queue 1: Best Effort    (DWRR: 5%)    |        |         |
|              +---------------------------------------+        |         |
|              | Queue 0: Scavenger      (DWRR: Min)   |        |         |
|              +---------------------------------------+                  |
+-------------------------------------------------------------------------+

Local Priority Mapping

When a packet ingresses an AOS-CX switch, the forwarding engine determines its Local Priority (an internal value from 0 to 7) based on the port's trust state and mapping tables (cos-map or dscp-map). Once the switching fabric forwards the packet toward the target egress port, the switch evaluates the active Queue Profile (qos queue-profile) to place the packet into the appropriate hardware egress queue.

On 8-queue platforms the factory-default queue profile maps Local Priority 0–7 directly to Queue 0–7, and the factory-default schedule profile uses DWRR with a weight of 1 on every queue, so no queue is strict priority until you configure one.

---

Queuing and Scheduling Algorithms

A scheduling algorithm determines the exact mathematical order and frequency with which a switch port's hardware queues transmit packets onto the physical wire.

1. First-In, First-Out (FIFO) Queuing

• Mechanism: All arriving packets enter a single queue buffer and are transmitted strictly in the order they arrived, regardless of packet type, CoS tag, or DSCP value.
• Limitations: FIFO provides zero traffic differentiation. If a large FTP transfer or video download fills the buffer, time-sensitive VoIP packets arriving behind the bulk data must wait until the entire buffer empties. This induces massive latency and jitter, rendering FIFO completely unsuitable for converged enterprise networks.

2. Strict Priority (SP) Scheduling

• Mechanism: Queues are prioritized in strict hierarchical order. The scheduler always inspects the highest-numbered queue (e.g., Queue 7). As long as Queue 7 contains a single packet, it is transmitted immediately. Only when Queue 7 is completely empty does the scheduler inspect Queue 6, and so forth down to Queue 0.
• Strengths: Provides the lowest possible latency and jitter. Ideal for real-time voice RTP packets (Queue 7).
• The Starvation Hazard: If an unpoliced video stream or denial-of-service flood fills Queue 7, the scheduler continuously services Queue 7 and never visits Queues 0 through 6. All lower-priority queues experience complete packet starvation, causing critical business applications, DNS resolution, and TCP sessions to drop.

3. Deficit Weighted Round Robin (DWRR) Scheduling

To prevent queue starvation while maintaining differentiated service, modern switches implement Deficit Weighted Round Robin (DWRR).

• Weight Allocation: Each queue is assigned a configurable weight representing a percentage of available port bandwidth (e.g., Queue 4 = 30%, Queue 3 = 20%, Queue 2 = 10%).
• The Variable Frame Size Challenge: Standard Weighted Round Robin (WRR) assumes fixed-length packets. In Ethernet networks, however, frame sizes vary wildly—from 64-byte TCP ACKs to 1518-byte standard frames and 9000-byte jumbo frames. Under simple WRR, a queue servicing 1500-byte frames receives far more bandwidth than a queue servicing 64-byte frames.
• Deficit Counter Mechanics: DWRR resolves this by assigning a quantum (a credit allocation in bytes proportional to the queue's assigned weight). In each round:
  1. The scheduler adds the quantum to the queue's deficit counter.
  2. If the deficit counter exceeds the byte size of the packet waiting at the head of the queue, the packet is transmitted, and its byte length is subtracted from the deficit counter.
  3. If the next packet is larger than the remaining deficit counter, the scheduler leaves the remaining credit intact and moves to the next queue.
  4. In the next round, the queue receives another quantum addition, allowing large frames to be transmitted fairly without over-consuming link capacity.
• Result: DWRR ensures predictable bandwidth distribution without starvation, regardless of packet size distributions.

4. Hybrid Scheduling (Strict Priority + DWRR)

The industry-standard best practice for campus access and aggregation switches is a hybrid scheduling model:

• Queue 7 (Voice): Configured for Strict Priority (SP) to guarantee immediate, zero-latency forwarding for latency-intolerant VoIP RTP audio.
• Queues 0 through 6 (Data & Video): Configured with DWRR weights to distribute remaining bandwidth equitably among video conferencing, database transactions, best-effort traffic, and scavenger streams.

---

Congestion Avoidance: Tail Drop vs. WRED

When sustained traffic bursts exceed an interface's transmission capacity, egress buffers fill. How the switch manages full or filling buffers determines overall application stability.

Tail Drop and the Threat of TCP Global Synchronization

Under standard Tail Drop, a switch takes no action while buffer space is available. However, once the egress queue buffer reaches 100% capacity, every subsequent arriving packet is dropped indiscriminately, regardless of its flow, importance, or protocol.

Tail Drop triggers a catastrophic network phenomenon known as TCP Global Synchronization:

Throughput
   ^        /\          /\          /\       <-- Simultaneous TCP Ramp-Up (Congestion Avoidance)
   |       /  \        /  \        /  \ 
   |      /    \      /    \      /    \ 
   | ----/------\----/------\----/------\--- <-- 100% Buffer Full (Tail Drop Event)
   |    /        \  /        \  /        \ 
   |   /          \/          \/          \  <-- Simultaneous TCP Window Collapse (Slow Start)
   +-----------------------------------------> Time

1. Multiple independent TCP streams share a congested uplink.
2. When the buffer reaches 100%, Tail Drop discards packets across all active TCP sessions simultaneously.
3. The endpoints detect packet loss via missing ACKs, assume severe network collapse, and simultaneously throttle their TCP Congestion Window (cwnd) down to 1 MSS (Maximum Segment Size), entering TCP Slow Start.
4. Link utilization abruptly plunges to near zero.
5. As packets are acknowledged, all endpoints simultaneously ramp up their window sizes, flooding the buffer again and triggering another round of Tail Drop.
6. This continuous "sawtooth" oscillation severely degrades campus throughput and causes massive jitter.

Weighted Random Early Detection (WRED)

Weighted Random Early Detection (WRED) solves TCP global synchronization and bufferbloat by dropping packets proactively before the queue buffer exhausts.

Drop Probability
   ^
100%|                                      +------------------ (100% Drop / Tail Drop)
   |                                     / |
   |                                    /  |
Max|                                  /    |
Drop|                                /     |
   |            Marking A (AFx3)    /      |
   |           /                   /       |
   |          /  Marking B (AFx1) /        |
 0% +---------+------------------+---------+------------------> Average Queue Depth
              ^                  ^
           Min Threshold      Max Threshold
           (Drops Begin)      (Tail Drop Zone)

How WRED Operates

1. Average Queue Depth Monitoring: Rather than reacting to instantaneous bursts, WRED calculates an exponentially weighted moving average queue depth.
2. Minimum Threshold (TH_min): When the average queue depth is below TH_min, all packets are admitted into the buffer (0% drop rate).
3. Random Proactive Drops: When queue depth rises between TH_min and TH_max, WRED begins dropping a small, randomized percentage of packets. Because the drops are randomized across individual flows, only one or two TCP sessions experience packet loss. Those specific sessions back off their transmission rate, while all other sessions continue transmitting at full speed. This desynchronizes the TCP flows, smoothing aggregate throughput and keeping link utilization near 100%.
4. Maximum Threshold (TH_max): If congestion continues and queue depth exceeds TH_max, WRED reverts to tail drop (100% drop rate) to protect switch ASIC memory.
5. Differentiated Drop Precedence: The "Weighted" aspect of WRED means that the switch maintains different threshold curves based on packet markings. Packets with high drop precedence (such as AF43 or AF13) hit a lower TH_min and face higher drop probabilities, while packets with low drop precedence (such as AF41 or AF11) are protected until buffers reach much deeper thresholds.

---

AOS-CX Queue and Schedule Profile Configuration

Configuring queuing and scheduling on Aruba AOS-CX switches follows a structured two-part hierarchy: defining the Queue Profile (queue structure) and defining the Schedule Profile (servicing behavior).

Step 1: Configuring the Queue Profile

The queue profile defines the number of queues and maps internal Local Priorities (0–7) to hardware queues:

switch# configure
switch(config)# qos queue-profile Campus-Queues
switch(config-queue)# map queue 0 local-priority 0
switch(config-queue)# map queue 1 local-priority 1
switch(config-queue)# map queue 2 local-priority 2
switch(config-queue)# map queue 3 local-priority 3
switch(config-queue)# map queue 4 local-priority 4
switch(config-queue)# map queue 5 local-priority 5
switch(config-queue)# map queue 6 local-priority 6
switch(config-queue)# map queue 7 local-priority 7
switch(config-queue)# exit

Step 2: Configuring the Schedule Profile

The schedule profile defines how the queues configured in Step 1 are scheduled onto the wire:

switch(config)# qos schedule-profile Campus-Schedule
switch(config-schedule)# strict queue 7
switch(config-schedule)# dwrr queue 6 weight 25
switch(config-schedule)# dwrr queue 5 weight 20
switch(config-schedule)# dwrr queue 4 weight 20
switch(config-schedule)# dwrr queue 3 weight 15
switch(config-schedule)# dwrr queue 2 weight 10
switch(config-schedule)# dwrr queue 1 weight 5
switch(config-schedule)# dwrr queue 0 weight 5
switch(config-schedule)# exit

Step 3: Applying Profiles Globally or to Interfaces

Globally, the queue profile and schedule profile are applied together in one command; on an interface or LAG, only a schedule profile can be applied (AOS-CX 10.14 QoS Guide):

switch(config)# apply qos queue-profile Campus-Queues schedule-profile Campus-Schedule
switch(config)# interface 1/1/48
switch(config-if)# apply qos schedule-profile Campus-Schedule

Step 4: Verification and Queue Monitoring

Verify queuing operation and monitor drop counters using the following CLI commands:

switch# show qos queue-profile Campus-Queues
Queue Profile : Campus-Queues

Queue   Local Priorities
-----   ----------------
0       0
1       1
2       2
3       3
4       4
5       5
6       6
7       7

switch# show qos schedule-profile Campus-Schedule
Schedule Profile : Campus-Schedule

Queue   Algorithm   Weight / Burst
-----   ---------   --------------
7       strict      N/A
6       dwrr        25
5       dwrr        20
4       dwrr        20
3       dwrr        15
2       dwrr        10
1       dwrr        5
0       dwrr        5

switch# show interface 1/1/48 queues
Interface 1/1/48 (Egress Queues, abbreviated):

Queue   Tx Packets          Tx Bytes            Drop Packets        Drop Bytes
-----   ------------------  ------------------  ------------------  ------------------
7       1842039             217356602           0                   0
6       4829103             4982390123          120                 154320
5       1293847             1283749102          0                   0
1       84920194            102938471928        2490                3819200