Quality of Service (QoS) Congestion Management Notes

Of all the tools within the QoS toolset, congestion management tools, also known as queuing tools, provide the biggest impact on application service levels.  Whenever packets enter a device faster than can exit it, congestion exists and this is where queuing tools come into play.  Queuing tools are only engaged when congestion exists, otherwise packets are sent as soon as they arrive.  When congestion does exist, packets must be buffered, or queued, to mitigate dropping.

Packet markings, or lack thereof, affect queuing policies, so queuing policies are complementary and have a dependence on classification and marking policies.

Scheduling vs. Queuing

These two terms are often incorrectly used interchangeably – they are two different things.  Scheduling determines how a frame or packet exits a device. Whenever packets enter a device faster than they can exit it, as is the case with speed mismatches (ex. Gigabit Ethernet traffic heading to a WAN interface), congestion can occur.  Devices have buffers that allow the temporary storing and subsequent scheduling of these backed-up packets, and this process is called queuing.

Inbound traffic > Queuing (During congestion) > Scheduling > Outbound traffic

• Queuing – orders packets in linked output buffers. Only engaged when there is congestion
• Scheduling – decides which packet to transmit next.  This occurs whether there is congestion or not (Although the scheduling decision is of course much simpler when there is no congestion).

During congestion, the scheduler has to make a decision of what queue to service first based on various types of scheduling logic algorithms:

• Strict Priority – Lower-priority queues are served only if higher-priority queues are completely empty.  This can potentially starve out lower priority queues. Strict priority is good for real-time, delay-sensitive traffic.
• Round-robin – Services queues in a sequence.  Doesn’t have the potential to starve traffic, but may not provide the level of service that delay-sensitive traffic needs that Strict Priority scheduling would be able to provide.
• Weighted-fair – Packets in queues are weighted so that some queues are serviced more frequently than others.  Addresses the cons of strict priority and round-robin, but doesn’t guarantee the bandwidth that real-time flows may require.

Congestion Management vs. Congestion Avoidance

The amount of buffer space (memory) for queues is of course limited.  Once the buffer is overrun, packets may be dropped as they arrive (tail drop), or proactively beforehand.  The selective, proactive dropping of packets is called congestion avoidance.  Congestion avoidance works best with TCP-based applications since the selective dropping causes the TCP windowing mechanism to engage and throttle back the rate of traffic flow to a manageable state.  The relationship between this and congestion management is that the scheduling algorithms of congestion management manage the front of a queue, where with congestion avoidance, the mechanisms manage the tail of a queue.

Legacy L3 Queuing Mechanisms

These are considered legacy, but are what newer mechanisms are built upon:

• Priority queuing (PQ)
• Custom queuing (CQ)
• Weighted Fair Queuing (WFQ)

Newer queuing mechanisms used combinations of these while also attempting to minimize drawbacks, such as:

• Class-based Weighted Fair Queuing (CBWFQ)
• Low latency queuing (LLQ)

Priority Queuing

• Only consists of 4 queues (high, medium, normal/default, low)
• Scheduler empties high queue first before servicing lower queues.
• So, similar to strict priority queuing, handles real-time traffic well but risks starving other queues.

Custom Queuing

• Introduced a round-robin scheduler based on byte counts.
• Prevented bandwidth starvation and introduced bandwidth guarantees
• Supports up to 16 queues
• No capability to provide strict priority

Weighted Fair Queuing

• Built to expand upon principle of fairness that CQ introduced
• Simply divided interface bandwidth by number of flows
• Added a fixed weight based on IPP for bandwidth calculation to favor higher-priority flows, based on that IPP marking
• No ability to provide bandwidth guarantees due to bandwidth allocation changing as flows are added and ended

Currently Recommended L3 Queuing Mechanisms

Enhanced mechanisms were developed to utilize the strengths of the legacy mechanisms while minimizing their weaknesses.

Class-Based Weighted Fair Queuing

• Hybrid queuing algorithm that combines guaranteed bandwidth (from CQ) with the ability to dynamically ensure fairness to other flows within a class of traffic (from WFQ)
• Up to 256 classes of traffic with reserved queues
• Each queue is serviced based on assigned bandwidth
• Minimum bandwidth is explicitly defined and enforced
• Uses Modular QoS CLI (MQC)-based class maps for classification

CBWFQ lacks the ability to provide strict-priority queuing for real-time applications.  To service real-time applications, a strict-priority queue was added to the CBWFQ algorithm, and low-latency queuing (LLQ) was born.

Low Latency Queuing

• Enhanced combination of PQ, CQ, and WFQ.
• Basically CBWFQ with a strict PQ.
• Has a built-in policer to to prevent the strict-priority queue from starving lower-priority traffic
• Only engages when there is congestion, so it is important to provision priority classes properly

Bandwidth Provisioning in LLQ

• General best practice is to provide at least 25% of a link’s bandwidth to class-default
• Limit the sum of all priority class traffic to no more than 33% of a link’s capacity.
• All bandwidth guarantees within LLQ should be no more than 75% link capacity.
• When the percentage-remaining (bandwidth remaining percent) form of LLQ is used, this rule goes out the window because it utilizes a percentage of the remaining bandwidth after the PQ is serviced rather than a set value.