Class in Session: Cisco

Part 11 of this blog series looked at Class Based Weighted Fair Queuing. This blog will explore the next queue mechanism; Low Latency Queuing (LLQ).

As seen in the previous section of this QoS series, CBWFQ provides user defined traffic classes allowing for more control and functionality than weighted Fair Queuing. CBWFQ uses matching criteria obtained by Network Based Application Recognition (NBAR), or access control lists (ACLs). A queue is reserved for each class and matching traffic is directed to that queue.

Low Latency Queuing
LLQ adds strict priority to the CBWFQ and allows delay sensitive data (Voice and Video) to be dequeued and sent before lower priority packets. This practice gives delay sensitive data preferential treatment over other traffic. To direct traffic to the LLQ, use the priority command for the class after the named class within a policy map is specified. Any class of traffic can be attached to a service policy, which uses priority scheduling, and that traffic can be prioritized over other class traffic.

When you specify the priority command for a class, it takes a bandwidth argument that gives maximum bandwidth in kilobits per second (kbps). Use this parameter to specify the maximum amount of bandwidth allocated for packets belonging to the class configured with the priority command. The bandwidth parameter both guarantees bandwidth to the priority class and restrains the flow of packets from the priority class.

Without Low Latency Queueing, CBWFQ provides weighted fair queuing based on defined classes with no strict priority queue available for real-time traffic. CBWFQ allows you to define traffic classes and then assign characteristics to that class. For CBWFQ all packets are serviced fairly based on weight; no class of packets may be granted strict priority. This scheme poses problems for voice traffic that is largely intolerant of delay, especially variation in delay. For voice traffic, variations in delay introduce irregularities of transmission manifesting as jitter in the heard conversation.

LLQ Configuration

In this configuration notice that the Class-Map VoIP sets the IP Precedence of 5, which sets all traffic with an IPP of 5 to this class. The priority command within the policy-map indicates the VoIP Class is a Priority Queue (PQ) and this traffic will get priority over other queues. In this example, the priority is set to 10% of the bandwidth for this traffic.

Priority Bandwidth = Allocates a fixed amount of bandwidth to a class to ensure expedited forwarding.
Priority Percent = Allocates a percentage of the configured or default interface bandwidth to ensure expedited forwarding.

LLQ Show Command

Author: Paul Stryer

References

• Cisco IOS Quality of Service Solutions Configuration Guide, Release 12.4T
• End-To-End QoS network Design, by Tim Szigeti and Christina Hattingh – ISBN # 1-58705-176-1
• DiffServ – The Scalable End-To-End QoS Model
• Integrated Services Architecture
• Definition of the Differentiated Services Field
• An Architecture for Differentiated Services
• Requirements for IP Version 4 Routers
• An Expedited Forwarding PHB (Per-Hop Behavior)

Part 10 of this blog series looked at Weighted Fair Queuing, so now we move on to the next queue mechanism; Class Based Weighted Fair Queuing (CBWFQ).

CBWFQ provides user defined traffic classes allowing for more control and functionality then weighted Fair Queuing. CBWFQ uses matching criteria obtained by Network Based Application Recognition (NBAR), or access control lists (ACLs). A queue is reserved for each class and matching traffic is directed to that queue.

Low Latency Queuing (LLQ) adds priority to the CBWFQ and allows delay sensitive data to be dequeued and sent before lower priority packets, giving delay sensitive data preferential treatment over other traffic. LLQ will be discussed in the next part of this QoS series.

Class Based Weighted Fair Queuing
Once the packets have been matched and the class is defined, a characteristic is assigned to the class. The characteristics that are assigned are bandwidth, weight, and maximum packet limit. The bandwidth is the minimum bandwidth delivered to the class during congestion, and the maximum packets is how many packets are allowed to accumulate in the class queue before tail drops start happening to the worst finish time packets.

CBWFQ supports multiple class maps to classify traffic, with tail drop being the default dropping scheme. Weighted random early detection (WRED) can be used with CBWFQ to prevent class congestion. Guaranteed bandwidth is configured by weights and assigned to traffic classes. The following weights can be used to specify class weight. The reserve default is set to 75%, and must be within the allocated bandwidth. Single service policies cannot mix fixed bandwidth and bandwidth percentages commands.

• Bandwidth = This command allocates a fixed amount of bandwidth and the reserve bandwidth is subtracted from the available bandwidth of the interface where the service policy is used.
• Bandwidth percent = This command is used to allocate a percentage of the default or available bandwidth of an interface.
• Bandwidth remaining percent = This command allocates a portion of the unallocated bandwidth.

Continue reading ‘Quality of Service, Part 11: CBWFQ’

In part 8 of this blog series congestion management and its four main queuing methods were explored. This post will look at the first of four queuing methods: First In First Out (FIFO) queuing.

To refresh our memories, congestion can occur anywhere within a network, such as sections of the network that have speed mismatches, aggregations points, or confluences. Queuing algorithms are used to manage congestion. There are many different algorithms to serve multiple needs. The ultimate goal is to provide bandwidth and delay guarantees in order to prioritize the network traffic.

Speed mismatches occur when traffic moves from one speed network (such as a 100Mbps LAN) to another network with a different speed (Such as a 10Mbps LAN). This could be a LAN-to-LAN or LAN-to-WAN mismatch; however, usually it is a high speed to a low speed connection.

Aggregation congestion occurs when multiple connections feed into one main connection. A typical situation would be when multiple remote sites connect into one central site. For example if you have twenty remote sites with 256K WAN links that all connect to the headquarters via a single T1 connection, it would be very easy for the T1 connection to become oversubscribed.

Queuing Components
Queuing accommodates bursts on the router when the arrival rate of packets is greater than the departure rate. Two main reasons for bursts are the cause of queuing to be used:

1. Input interface is faster than the output interface
2. Output interface is receiving packets coming in from multiple other interfaces

Queuing is split into two parts:

1. Hardware queue: Uses FIFO , and is sometimes called the transmit queue (TxQ)
2. Software queue: Schedules packets into the hardware queue based on the QoS settings

A full hardware queue indicates interface congestion and software queuing is used to manage it. When a packet is being forwarded, the router will bypass the software queue if the hardware queue is not full.
First In First Out(FIFO)  Queuing

FIFO queuing algorithm is the simplest of the congestion management methods. All packets are treated equally, and placed into a single queue and serviced the order they were received. Hence the name FIRST-IN FIRST-OUT. FIFO queuing offers the following benefits:

• FIFO is supported on all Cisco Platforms
• FIFO queuing is supported in all version of Cisco IOS
• FIFO queuing places an extremely low load on the system when compared with other queuing mechanisms.
• FIFO queuing is predictable, and delay is determined by the maximum depth of the queue.
• FIFO queuing does not add significant queuing delay at each hop as long and the queue depth remains low.

FIFO queuing also poses the following limitations:

• FIFO queuing is extremely unfair when an aggressive flow contests with a time sensitive flow. Aggressive flows send a large number of packets, many of which are dropped. Time sensitive flows send a modest number of packets and most are dropped due to the queue always being full of aggressive flow packets. This behavior is called starvation.
• When the Queue is full, packets entering the queue have to wait longer. When the queue is not full, packets entering the queue do not have to wait as long as when the queue was full. Variation in delay is called Jitter.
• A single FIFO queue does not allow routers to organize buffered packets and service one class of traffic differently from other classes of traffic.
• During periods of congestion, FIFO queuing benefits UDP flows over TCP flows. When experiencing packet loss due to congestion, TCP based applications reduce their transmission rate. UDP based applications remain oblivious to packet loss and continue transmitting packets at their usual rate. Because TCP based applications slow their transmission rate to adapt to changing network conditions, FIFO queuing can result in increased delay, jitter, and a reduction in the amount of output bandwidth consumed byTCP applications.

Author: Paul Stryer

References

• Cisco IOS Quality of Service Solutions Configuration Guide, Release 12.4T
• End-To-End QoS network Design, by Tim Szigeti and Christina Hattingh – ISBN # 1-58705-176-1
• DiffServ – The Scalable End-To-End QoS Model
• Integrated Services Architecture
• Definition of the Differentiated Services Field
• An Architecture for Differentiated Services
• Requirements for IP Version 4 Routers
• An Expedited Forwarding PHB (Per-Hop Behavior)