Cisco QoS 4 - Speed Guarantee - Queuing

Congestion Management - Queuing

A queue is essentially memory that is used when the rate of incoming packets is greater than the outgoing rate. At that time, packets are stored in the queue, and according to the queue algorithm, they are removed and sent. If the queue didn't exist, the packets would be dropped immediately. If the incoming rate is lower, the queue is not used.

Note: Software interfaces (such as subinterfaces or tunnels) don't have queues.

On Cisco devices, a wide range of queuing mechanisms can be used, depending on the device and IOS. Some main mechanisms are:

First In First Out - FIFO - default for links above 2Mbps, packets leave in the order they arrived
Weighted Fair Queuing - WFQ - default for links below 2Mbps, bandwidth distribution according to weight
Class Based Weighted Fair Queuing - CBWFQ - using classes
Low Latency Queuing - LLQ - creates priority queues along with CBWFQ
IP RTP Prioritization - adds low-latency queuing capability to WFQ and CBWFQ, suitable for VoIP, adds a special queue that is prioritized, traffic is defined using a range of UDP ports

Note: Queue implementations differ according to hardware devices, the main difference is between smaller routers and between switches and large routers that use special hardware.

Each interface has a hardware queue, which is of type FIFO. Before the HW queue, there are software queues, to which we can apply any of the supported queue types. The router tries to minimize the size of the HW queue to minimize the FIFO part of the queuing model. If the SW queue is empty and there's still space in HW, the SW queue is bypassed and the packet doesn't get into it at all (this can be a common case in LAN). The size of the HW queue can be changed for the interface with the tx-ring-limit command, but it's not recommended.

First In First Out - FIFO

uses only one queue (one traffic class)
before the queue is Tail Drop - if the queue is full, the packet is dropped
it's the default mechanism for links above 2Mbps
supported everywhere and simple
not efficient (causes congestion where aggressive flows occupy the entire link, and jitter)

If we want to turn it on on a slower interface (serial line) where WFQ is default, we do it by turning off WFQ

ROUTER(config-if)#no fair-queue

Information about the chosen queue can be seen in the interface detail:

SWITCH#show interface g1/0/2
GigabitEthernet1/0/2 is up, line protocol is up (connected)
...
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
...

Weighted Fair Queuing - WFQ

fair queuing - should fairly distribute bandwidth between data flows
traffic is divided into flows (given by addresses, protocol.), each flow has its queue
weight - adds weight setting, according to which some flow gets more bandwidth
distribution into queues is done using a hash, which is calculated from TCP and IP headers - hash is the index of the queue to which it's assigned
there's a fixed number of queues, which must be greater than the expected number of different flows
easy to configure and works automatically
doesn't allow guaranteeing bandwidth
default mechanism for slow links (up to 2Mbps) or if a service-policy that uses queues is applied to the interface

For packet dropping, Modified Tail Drop is used, which works either as early dropping - drops earlier than when it's full (according to settings) or aggressive dropping - only when reaching the maximum. More aggressive (voluminous) flows are always dropped the most. If something needs to be dropped, the last packet from the longest queue is dropped, so it might not be the packet that came last. Queue length is evaluated according to finish time (time when the packet would be fully sent, so it depends on packet size and not on count).

ROUTER(config-if)#fair-queue // turns on WFQ, parameters may follow
ROUTER#show queueing fair    // shows the state of WFQ configuration
ROUTER#show queue f0/2       // information about the queue for the interface

Class Based Weighted Fair Queuing - CBWFQ

allows guaranteeing bandwidth to individual classes
a separate queue is used for each class, maximum is 64 classes and one default (where everything else falls, uses FIFO)
we can set bandwidth, percentage of bandwidth or percentage of available bandwidth
it works so that we define a class and set it guaranteed bandwidth, which the class gets during congestion, we can also set the queue size
when the queue is full, Tail Drop is used, or we can configure WRED
from the set bandwidth, the weight for the given class is determined
by default, 25% of the bandwidth must remain free on the interface (we can define max. 75%), but it can be changed through configuration

Note: We can also modify properties for class-default, for example set fair-queue instead of FIFO.

ROUTER(config-pmap-c)#bandwidth 1024        // fixed bandwidth allocation in kbps
ROUTER(config-pmap-c)#bandwidth percent 50  // percentage
ROUTER(config-pmap-c)#bandwidth remaining percent 20 // percentage of available bandwidth
ROUTER(config-pmap-c)#queue-limit 20        // queue size, number of packets
ROUTER(config-if)#max-reserved-bandwidth 80 // we change the default 75%
ROUTER#show policy-map interface f0/1       // information about applied policy-map includes info about queues
ROUTER#show queueing interface f0/1         // shows current mechanism on the interface

Low Latency Queuing - LLQ

most used
high priority queues are created, which have guaranteed bandwidth and low latency, at the same time they are policed to not exceed the given bandwidth (to not take up the entire bandwidth), but only in case of congestion (bandwidth filling), otherwise traffic can exceed the given value
LLQ adds a strictly priority queue to CBWFQ, which reduces jitter in voice transmission
allows creating one priority queue inside CBWFQ at class level
for a class that uses LLQ, we can't use WRED or define queue size

ROUTER(config-pmap-c)#priority 1024       // guarantees and limits exactly given bandwidth in kbps, ensures expedited forwarding
ROUTER(config-pmap-c)#priority percent 25 // similar, but in percentages

Congestion Avoidance

In the previous section, we dealt with congestion management so that some traffic wouldn't get the entire bandwidth while others would be constantly dropped. Queues helped us with this, from which traffic was selected by a certain algorithm. In this section, we'll try to prevent congestion by using early smart dropping.

By default, the Tail Drop mechanism is used. It treats every traffic the same, when the queue is full, packets are dropped until the congestion subsides. Dropping packets causes other problems, such as reducing speed on TCP, retransmission, synchronization due to TCP Windows, etc. If we use long queues, delay increases, different sized queues cause jitter, aggressive flows take up a larger part of the queue, so others are dropped more. In some places, an improved method Weighted Tail Drop - WTD is used. Here, certain traffic (according to weight) starts to be dropped earlier than others.

Therefore, better methods are used. The most widespread are variations of the Random Early Detection (RED) algorithm. By intelligently dropping packets before the queue is filled, we can slow down TCP sessions (from the principle of TCP - it responds to dropped packets by slowing down).

The behavior of traffic during congestion is such that globally synchronized waves of congestion occur, followed by underutilization of the entire bandwidth. This is because when congestion occurs, all traffic starts to be dropped, all TCP connections thus slow down, and therefore in total, free bandwidth remains and speed starts to increase again. And so everything repeats.

Some variations of RED are:

Random Early Detection - RED - randomly drops packets before the queue fills up, average queue length is low (own data flows are slowed down, TCP window is reduced), works in three modes, first it doesn't drop, as the queue grows it randomly drops, at the end is tail drop
Weighted Random Early Detection - WRED - according to weight there are different profiles of when and how it drops, so more important flows are dropped less, has default profiles for IP Precedence and DSCP, but we can change, configured on the interface using random-detect
Class Based Weighted Random Early Detection - CBWRED - extension for classes, configured on policy-map

ROUTER(config-pmap-c)#random-detect              // uses IP Precedence default profile
ROUTER(config-pmap-c)#random-detect dscp-based   // uses DSCP default profile
ROUTER(config-pmap-c)#random-detect dscp 3 20 40 // changes DSCP profile, values are DSCP, min-threshold, max-threshold