Quality of Service (QoS)

CIS 187 Multilayer Switched Networks

CCNP
Rick Graziani
Spring 2009

Overview

Previously an organization would use separate networks for:

Voice
Video
data traffic
Now common practice to combine these into a single multi-service network in
which the varied traffic types coexist.

Overview

QoS Issues over non-QoS networks:

Stop-start and choppy Internet streaming video performance
Harsh audio when using Internet based IP phone

Quality of Service
defined

QoS refers to the ability of a network to provide improved service

to selected network traffic over various underlying technologies
including Frame Relay, ATM, Ethernet and IP-routed networks.
QoS features provide improved and more predictable network service
by offering the following services:
Dedicated bandwidth
Improved loss characteristics
Congestion management and Avoidance
Traffic Shaping
Prioritization of traffic

Quality of Service defined

The goal is to move information from one point to another

and the characteristics that define the quality of this
movement are:
Delay
Delay Variation (also known as Jitter)
Loss

Loss

Loss refers to the percentage of packets that fail to

reach their destination.
Loss can result from:
Errors in the network
Corrupted frames
Congested networks

Loss
TCP Header
UDP Header

Packet loss in a healthy network are actually deliberately dropped by

networking devices to avoid congestion. (later)

TCP:
TCPs retransmission mechanism
UDP:
Some loss may be acceptable
As a guide, a highly available network should suffer less than 1% loss
and for voice traffic the loss should approach 0%.

Delay or latency

Delay or latency refers to the time it takes for a packet to travel from

the source to the destination.

Fixed delays
Serialization and encoding/decoding.
For example, a bit takes a fixed 100ns to exit a 10Mb Ethernet
interface.
Variable delays
Congestion and time packets spend in network buffers waiting for
access to the media.
As a design rule the total time it takes a voice packet to cross the network
should be less than 150ms (ms, millisecond = 1,000 th of a second).

Delay variation or jitter

Delay variation or jitter is the difference in the delay times of

consecutive packets.
A jitter buffer used to smooth out arrival times.
Increases total network delay.
In general, traffic requiring low latency also requires a minimum
variation in latency.

Delay variation or jitter

As a design rule, voice networks cannot cope with more than 30ms of
jitter.
Jitter in excess of 30ms will result in degraded audio performance.
Excessive jitter in a streaming video environment will result in:
Jerky motion
Loss of video quality
Loss of video

Network availability

Highly available network uses:

Redundancy
Dynamic routing protocols
Hot Standby Routing Protocol (HSRP)
Spanning Tree Protocol (STP)

Provisioning

Bandwidth is not listed as an element of QoS.

Inadequate bandwidth inflates latency
It is not possible to meet QoS requirements if network LAN and WAN links
have insufficient bandwidth simply adding bandwidth, (also known as overprovisioning) will not solve the problem.
Over-provisioned network:
Good News: Less likely to be congested
Bad News: If it does become congested, the network may not perform
as well as a lower bandwidth network that makes use of QoS features.

Quality of Service
requirements for data

Some traffic can usually tolerate lower QoS levels.

Relative priority model divides traffic into four classes:
Gold (Mission-Critical) Transactional, software
Silver (Guaranteed-Bandwidth)Streaming video, messaging,
intranet
Bronze (Best-Effort and Default class)Internet browsing, E-Mail
Less-than-Best-Effort (Optional; higher-drop preferences)FTP,
backups, and applications (MySpace, YouTube, KaZaa)

Quality of Service
requirements for voice

Voice quality is directly affected by all

three QoS quality factors:
Loss
Delay
delay variation

Quality of Service requirements for video

Streaming video applications have more lenient QoS

requirements due to application buffering.

Quality of Service requirements for video

QoS needs of video conferencing traffic are similar to those for

voice.
Loss should be no more than 1%
One-way latency should be no more than 150-200ms
Average jitter should be no more than 30ms

Quality of Service mechanisms

Quality of Service mechanisms

Once the QoS requirements of the network have been defined, an

appropriate service model must be selected.
A service model is a general approach or a design philosophy for
handling the competing streams of traffic within a network.
There are three service models from which to chose;
Best-effort
Integrated
Differentiated

Best-Effort service
(single interface outbound queue)

(one packet at a time)

(relative time of arrival)

Best effort is a single service model in which an application sends data:

Whenever it must
In any quantity
Without requesting permission or first informing the network
For best-effort service, the network delivers data if it can, without any
assurance of:
Reliability
delay
throughput

Best-Effort service
(single interface outbound queue)

(one packet at a time)

(relative time of arrival)

Cisco IOS QoS implements best-effort service is FIFO queuing.

FIFO is the default method of queuing for LAN and high speed
WAN interfaces on switches and routers.
Best-effort service is suitable:
General file transfers
E-mail
Web browsing

Integrated services model

Integrated service or IntServ

The application requests a
specific kind of service from
the network before it sends
data.
The Cisco IOS IntServ model
makes use of the IETF Resource
Reservation Protocol (RSVP)
Used by applications to signal
their QoS requirements to the
router.
Drawbacks
Not scalable
Require continuous signalling
from network devices

Integrated services model

FYI

Routers, in conjunction with RSVP are able to use intelligent queuing

mechanisms to provide two types of services.
Guaranteed Rate Service, which allows applications to reserve bandwidth to
meet their requirements.
For example, a Voice over IP (VoIP) application can reserve 32 Mbps endto-end using this kind of service.
Cisco IOS QoS uses weighted fair queuing (WFQ) with RSVP to provide
this kind of service
Controlled Load Service, which allows applications to have low delay and
high throughput even during times of congestion.
For example, adaptive real-time applications such as playback of a
recorded conference can use this kind of service.
Cisco IOS QoS uses RSVP with Weighted Random Early Detection
(WRED) to provide this kind of service.

Differentiated services model

Differentiated Service or DiffServ architecture

Emerging standard from the IETF.
Each packet is classified upon entry into the network.
These are represented using the Type of Service (ToS)
field.
IP packet header:
IP precedence or
Differential Services Code Point (DSCP).

Differentiated services model

Once packets are classified at the edge by

Access layer switches
Border routers
Unlike the IntServ model, DiffServ does not require
network applications be QoS aware.

Traffic marking

Data Link Layer:

Ethernet frame has no fields to signify its QoS
requirements.
ISL or 802.1Q/P provides a 3 bit Class of Service
(CoS) field.
Gives Layer 2 switches the ability to prioritize traffic.

Traffic marking

At the Network layer an IP packet contains:

ToS:
IP-Precedence field
Differentiated Services Code Point (DSCP) fields.
Either of these can be used to signify the QoS
requirements of an IP packet.

Traffic marking
Layer 2

Layer 3

The decision of whether to mark traffic at layers 2 or 3 or both is not

trivial and should be made after consideration of the following points:
Layer 2 marking of frames can be performed for non IP traffic.
Layer 2 marking of frames is the only QoS option available for
switches that are not IP aware
Layer 3 marking will carry the QoS information end-to-end
Older IP equipment may not understand DSCP

CoS

The 3 bit CoS field present allows eight levels of priority.

0 lowest priority to 7 highest priority
Switches set a layer 2 CoS value for traffic based on
their ingress port
Router translate the CoS value into an equivalent IP
Precedence or DSCP value

ToS

ToS
IP DSCP value is the first 6 bits
IP Precedence value is the first 3 bits
The IP Precedence value is actually part of the IP DSCP value.
Therefore, both values cannot be set simultaneously.
DSCP supersedes IP Precedence.
A maximum of:
8 different IP precedence markings
64 different IP DSCP markings

Modular QoS command line

interface (CLI)

Modular QoS command line interface (CLI)

The Modular QoS Command Line Interface or MQC is central to

Ciscos model for implementing IOS based QoS solutions.
The MQC breaks down the tasks associated with QoS into modules
that:
Identify traffic flows
Classify traffic flows as belonging to a common class of QoS.
Apply QoS policies to that class
Define the interfaces on which the policy should be enforced
The modular nature of MQC allows the reuse of common traffic
classes and policies. This simplifies the configuration, makes it more
efficient to implement changes and reduces the chances of errors.

Example Modular QoS CLI

Interface

Interface

Interface

service-policy
output policy1

service-policy
output policy1

service-policy
output policy2

policy-map policy1
class class1
bandwidth
queue-limit
random-detect
class class2
bandwidth
queue-limit
random-detect

class-map class1
match input-interface

policy-map policy2
class class1
bandwidth
queue-limit
random-detect
class class3
bandwidth
queue-limit
random-detect

class-map class2
match access-group
access-list

class-map class3
match input-interface

Classification of traffic The class-map

Switch(config)# class-map cisco
Switch(config-cmap)#

The class-map command is used to define a traffic class.

The purpose of a traffic class is to classify or identify traffic that
should be given a particular QoS.
Traffic that matches a certain criteria.
A traffic class contains three major elements:
Name
Series of match commands
If more than one match command exists in the traffic class an
instruction on how to evaluate these match commands.

Classification of traffic The class-map

In the example below, any traffic that is permitted by the named ACL test will
be considered part of the traffic class known as cisco.

Switch(config)# class-map cisco

Switch(config-cmap)# match access-group name test

Match commands are used to specify various criteria for classifying

packets.
If a packet matches the specified criteria:
Packet is considered a member of the class
Packet is forwarded according to the QoS specifications set in
the traffic policy
Packets that fail to meet any of the matching criteria:
Classified as members of the default traffic class
Subject to a separate traffic policy

Classification of traffic
The class-map

If more than one match statement exists in the traffic class, use:
class-map match-any
or
class-map match-all

Note Catalyst 2950:

No match-any option
Default behaviour is to match-any
This can be overridden using the match-all command

Classification of traffic The class-map

If match-any is specified as the evaluation instruction, the traffic being

evaluated by the traffic class must match one of the specified

criteria.
If match-all is specified as the evaluation instruction, the traffic being
evaluated by the traffic class must match all of the specified criteria.

Switch(config)# class-map match-any cisco

Switch(config-cmap)# match access-group name test
Switch(config-cmap)# match interface fastethernet 0/1
If traffic matches a permit statement in the ACL test or the traffic
originates from FastEthernet 0/1 then it will be considered to be part of
the class of traffic known as cisco.

Defining the QoS policy The

policy-map

The policy-map command is used to create a traffic policy.

The purpose of a traffic policy is to configure the QoS features
that should be associated with the traffic that has been classified in
a user-specified traffic class.
A traffic policy contains three elements:
Policy Name
Traffic class (specified with the class command)
QoS policies to be applied to each class

Switch(config)# policy-map policy1

Switch(config-pmap)# class cisco
Switch(config-pmap-c)# bandwidth 3000
Switch(config-pmap)# class class-default
Switch(config-pmap-c)# bandwidth 2000

The policy-map shown creates a traffic policy named

policy1.
The policy applies to all traffic classified or identified
by the previously defined traffic-class cisco
Specifies that traffic in this example should be
allocated bandwidth of 3000 kbps.
Any traffic which does not belong to the class cisco
forms part of the catch-all class-default class
Will be given a default bandwidth of 2000 kbps.

Applying the policy to an interface The servicepolicy

Switch(config)# interface fastethernet 0/1
Switch(config-if)# service-policy output policy1

The service policy command is used to attach the traffic

policy, as specified with the policy-map command, to an
interface.
Can be applied to packets entering or leaving the
interface.

Applying the policy to an interface The servicepolicy

Switch(config)#interface fastethernet 0/1
Switch(config-if)#service-policy output policy1
Switch(config-if)#exit

All packets leaving the specified interface are evaluated according

to the criteria specified in the traffic policy named policy1.

Applying the policy to an interface The servicepolicy

Switch(config)#interface fastethernet 0/1
Switch(config-if)#service-policy output policy1
Switch(config)#policy-map policy1
Switch(config-pmap)#class cisco
Switch(config-pmap-c)#bandwidth 3000
Switch(config-pmap)#class class-default
Switch(config-pmap-c)#bandwidth 2000

Attach the traffic

policy to an interface

Identify the QoS

features of a Policy
using classes

Classify traffic
Switch(config)# class-map match-any cisco
flows as
Switch(config-cmap)# match access-group name test
Switch(config-cmap)# match interface fastethernet 0/1 belonging to a
Identify the traffic or traffic flows

common class
of QoS.

Any traffic which does not belong to the class cisco forms part of the catch-all classdefault class will be given a default bandwidth of 2000 kbps.

IP Precedence and DSCP

IP Precedence

3 bits = 8 possibilities.
Network control and Internetwork control classes are
usually reserved for router-generated packets such as
routing updates, ICMP messages, etc.
To protect packets that are necessary for the health of
the network.
Only 6 usable classes for production.

DSCP

The Differentiated Service Code Point is a selector for

router's per-hop behaviors.
DSCP (like IP Precedence) can be used to provide
differential treatment to packets.
Up to 64 different aggregates/classes can be supported
Default DSCP = 000 000

Per Hop Behavior

IP Packet
IP Packet
IP Packet

Same
DSCP
Value

IP Packet

Behavior Aggregate (BA) - A collection of packets that have the same

DSCP value (also called a codepoint) and crossing in a particular
direction.
Per Hop Behavior (PHB) - The packet scheduling, queuing, policing,
or shaping behavior of a node on any given packet belonging to a BA,
and as configured by a Service Level Agreement (SLA) or policy.
To date, four standard PHBs are available to construct a DiffServenabled network and achieve coarse-grained, end-to-end CoS and
QoS.

Class-Selector PHBs (Defined in RFC-2474)

DSCP

IP Precedence

111 000 (56) Range = 56 thru 63

111 (7) Network Control

110 000 (48) Range = 48 thru 55

110 (6) Internetwork Control

101 000 (40) Range = 40 thru 47

101 (5) Critical

100 000 (32) Range = 32 thru 39

100 (4) Flash Override

011 000 (24) Range = 24 thru 31

011 (3) Flash

010 000 (16) Range = 16 thru 23

010 (2) - Immediate

001 000 (8) Range = 8 thru 15

001 (1) - Priority

000 000 (0) Range = 0 thru 7

000 (0) - Routine

To preserve backward compatibility with the IP-precedence scheme:

DSCP values of the form `xxx000,'
These codepoints are called class-selector codepoints.

These PHBs retain almost the same forwarding behavior as nodes

that implement IP-precedence based classification and forwarding.
These PHBs ensure that DS-compliant nodes can co-exist with IPprecedence aware node.

Expedited Forwarding and Assured Forwarding

Packets in AF13
will get dropped
before packets in
AF12, before
packets in AF11.

Expedited Forwarding (EF) PHB defines a premium service for video and VoIP.
Recommended DSCP is 101110
Assured Forwarding (AF) PHB defines a method by which BAs can be given
different forwarding assurances.
The AFxy PHB defines four AFx classes: AF1, AF2, AF3, and AF4.
Each class is assigned a certain amount of buffer space and interface
bandwidth, dependent on the SLA with the Service Provider/policy.
Within each AFx class (AFxy) it is possible to specify 3 drop precedence
values.

Classification at the Access Layer

Classification at
the Access Layer
Layer 2

Layer 3

QoS should be implemented end-to-end within a network.

Best to classify traffic as soon as possible.
Frames and packets can be marked as important by using:
Layer 2 Class of Service (CoS)
Layer 3 the IP Precedence/Differentiated Services Code Point
(DSCP)

Trusting the CoS

If Edge device (IP phone or application) is capable of setting the

CoS bits then other devices must decide whether to trust the device
or not.
The default action of switches:
Not to trust edge devices
Any frames that enter the switch have their CoS re-written to the
lowest priority of 0.
If the edge device can be trusted:
Default behaviour must be overridden
Access switch must be configured to simply switch the frame
leaving the CoS bits untouched.

Configuring CoS trust using the IOS

Depending on the switch model it may be necessary to first activate

QoS using the command:

switch(config)# mls qos

Required on both the Catalyst 3550 and 6500.

The Catalyst 2950 has QoS enabled by default.

Configuring CoS trust using the IOS

The trust is configured on the switch port using the command:

switch(config-if)# mls qos trust cos

Any ISL or 802.1Q/P frames that enter the switch port

will now have its CoS passed, untouched, through
the switch.
If an untagged frame arrives at the switch port,
the switch will assign a default CoS to the frame
before forwarding it.
Default CoS = 0
Can be changed using the interface configuration
command:
switch(config-if)# mls qos cos default-cos
default-cos is a number between 0 and 7

Assigning CoS on
a per-port basis

switch(config-if)# mls qos trust cos

switch(config-if)# mls qos cos default-cos

If the incoming frame has a CoS, maintain the same CoS.

If the incoming frame has no CoS (0), apply the default CoS.

Re-writing the
CoS

Switch(config-if)# mls qos cos override

switch(config-if)# mls qos cos default-cos

May be desirable not to trust any CoS value that may

be present in frames sourced from an edge device.
Override parameter - ignores any existing CoS value
Apply the default value.

Using a MAC ACL to assign a DSCP value

It is not always possible to classify the CoS of a frame, based on

an ingress (incoming) port.
Ingress port is connected to multiple hosts through a hub
Simple workgroup switch that does not support QoS classification

Using a MAC ACL to assign a DSCP value

Switch(config)# mac access-list extended name

Configuring DSCP using a MAC ACL

Create the condition criteria.

Switch(config)# mac access-list extended receptionphone
Switch(config-ext-macl)# permit host 000.0a00.0111 any

Example
Set the DSCP field of packets coming from a single IPPhone (called receptionphone) within a switched network.
IP-Phone MAC address is 000.0a00.0111

Configuring DSCP using a MAC ACL

Identify the traffic or traffic flows

Switch(config)# class-map match-all ipphone
Switch(config-cmap)# match access-group name receptionphone
Create the condition criteria.
Switch(config)# mac access-list extended receptionphone
Switch(config-ext-macl)# permit host 000.0a00.0111 any

A class-map is used to link the identified traffic to a particular class of service.

In this case a class of service called ipphone is created.

Configuring DSCP using a MAC ACL

Switch# show class-map
Class Map match-any class-default (id 0)
Match any
Class Map match-all ipphone (id 2)
Match access-group name receptionphone

The creation of the class-map can be verified with the show classmap command

Configuring DSCP using a MAC ACL

Identify the QoS features of a Policy

Switch(config)# policy-map inbound-accesslayer
Switch(config-pmap)# class ipphone
Switch(config-pmap-c)# set ip dscp 40

Now a policy map is used to define the action that should

be taken on any traffic that forms part of that class.

In this case the policy will be called inbound-accesslayer
and the action is to set DSCP for the packets to 40.

Configuring DSCP using a MAC ACL

Cisco Switches support mapping

DSCP or IP Precedence

CoS

DSCP 0

16

24

32

40

48

56

IP
Prec

Configuring DSCP using a MAC ACL

Switch# show policy-map
Policy Map inbound-accesslayer
class ipphone
set ip dscp 40

The show policy-map command can be used to verify any policy-map

configuration.

Configuring DSCP using a MAC ACL

Attach the traffic policy to an interface.

Switch(config)# interface range fastethernet 0/1 - 24
Switch(config-if-range)# service-policy input inboundaccesslayer

In this case the policy will be applied to all the

interfaces so that QoS will be maintained regardless of
the interface the IP-Phone is connected to.

Configuring DSCP using a MAC ACL

Switch# show mls qos interface fastethernet 0/1
FastEthernet0/1
Attached policy-map for Ingress: inbound-accesslayer
trust state: not trusted
trust mode: not trusted
COS override: dis
default COS: 0
pass-through: none
trust device: none

The show mls qos interface command can be used to determine the
policies that are bound to a particular interface on the switch.

Configuring DSCP using a MAC ACL

Attach the traffic policy to an interface.
Switch(config)#interface range fastethernet 0/1 - 24
Switch(config-if-range)#service-policy input inboundaccesslayer
Identify the QoS features of a Policy
Switch(config)#policy-map inbound-accesslayer
Switch(config-pmap)#class ipphone
Switch(config-pmap-c)#set ip dscp 40
Identify the traffic or traffic flows
Switch(config)#class-map match-all ipphone
Switch(config-cmap)#match access-group name receptionphone
Create the condition criteria.
Switch(config)#mac access-list extended receptionphone
Switch(config-ext-macl)#permit host 000.0a00.0111 any

Another Example (FYI)

Using an IP ACL to define the DSCP or

precedence
Create the condition criteria.
Switch(config)# ip access-list extended 100
Switch(config-ext-nacl)# permit tcp any any eq ftp

Using the Modular QoS Command Line Interface (MQC) it is possible

to classify traffic based on its IP or TCP properties.
Scenario: In order to prevent large FTP downloads from disrupting
more critical services, the network administrator wishes to tag all FTP
packets entering an access-layer switch with either:
An IP Precedence of 0 (low) or
A DSCP of 0 (low) so that the traffic can be subjected to QoS
policies within the network.
In this case an IP ACL will be used to identify the packets.

Using an IP ACL to define the DSCP or

precedence
Identify the traffic or traffic flows
Switch(config)# class-map reducedservice
Switch(config-cmap)# match access-group 100

Traffic is classified as reducedservice if it is permitted by the

access list.

Using an IP ACL to define the DSCP or

precedence
Identify the QoS features of a Policy
Switch(config)# policy-map inbound-accesslayer
Switch(config-pmap)# class reducedservice
Switch(config-pmap-c)# set ip dscp 0

Policy-map is used to set the DSCP to 0 for this class of traffic.

Using an IP ACL to define the DSCP or

precedence
Identify the QoS features of a Policy
Switch(config)# policy-map inbound-accesslayer
Switch(config-pmap)# class reducedservice
Switch(config-pmap-c)# set ip precedence 0

Alternatively the IP precedence can be set using the following policymap.

Note:
Both the Catalyst 2950 and the Catalyst 3550 support the setting of
the DSCP.
The 3550 does support the setting of IP precedence.
The 2950 does not support the setting of IP precedence.
This is not a serious problem as the IP Precedence field forms the
first 3 bits of the DSCP. Thus by choosing and setting the
appropriate DSCP value, the IP Precedence can still be set.

Using an IP ACL to define the DSCP or

precedence
Attach the traffic policy to an interface.
Switch(config)# interface range fastethernet 0/1 - 24
Switch(config-if-range)# service-policy input inboundaccesslayer

Having now defined the action to be taken on FTP packets, the only
remaining step is to tell the switch which interfaces to apply the policy
to.
In this case the policy will be applied to all the interfaces so that QoS
will be maintained regardless of the interface an FTP source may be
connected to.

Using an IP ACL to define the DSCP or

precedence
Attach the traffic policy to an interface.
Switch(config)#interface range fastethernet 0/1 - 24
Switch(config-if-range)#service-policy input inbound-accesslayer

Identify the QoS features of a Policy

Switch(config)#policy-map inbound-accesslayer
Switch(config-pmap)#class reducedservice
Switch(config-pmap-c)#set ip dscp 0

Identify the traffic or traffic flows

Switch(config)#class-map reducedservice
Switch(config-cmap)#match access-group 100

Create the condition criteria.

Switch(config)#ip access-list extended 100
Switch(config-ext-nacl)#permit tcp any any eq ftp

Scheduling

Suggested Readings

Queuing overview

A protocol-dependent switching process handles traffic

arriving at a router interface.
This process includes delivery of traffic to an outgoing
interface buffer.
First-in, first-out (FIFO) queuing is the classic algorithm
for packet transmission.

Queuing
overview

Cisco IOS software offers three alternative queuing options:

Weighted fair queuing (WFQ)
Class-based weighted fair queuing (CBWFQ) - IOS 12.2 and later
Low latency queuing (LLQ) - IOS 12.2 and later
Queuing methods discussed in previously in CCNP, and have been
replaced somewhat by CBWFQ and LLQ
Custom Queuing replaced by CBWFQ
Priority Queuing replaced by LLQ

Effective use of traffic prioritization

Generalizations on Queuing:
If there is no congestion on the WAN link, traffic prioritization is
not necessary.
If a WAN link is constantly congested, traffic prioritization may not
resolve the problem.
Adding bandwidth might be the appropriate solution.

Establishing a queuing policy

Goal is to deploy and maintain a single enterprise network that

supports a variety of:
Applications
Organizations
Technologies
User expectations
Result: Provide all users with an appropriate level of service, while
continuing to support mission-critical applications.

Choosing a Cisco IOS queuing options

Custom
CBWFQ

Priority
LLQ (PQ/CBFQ)
WFQ

Typically, voice and video have the lowest

tolerance for delay.

Configuring Weighted Fair

Queuing

FIFO First In First Out

(single interface outbound queue)

(one packet at a time)

(relative time of arrival)

FIFO queuing is in effect, traffic is transmitted in the order received

without regard for bandwidth consumption or the associated delays.
Packet trains are groups of packets that tend to move together
through the network.
These packet trains can consume all available bandwidth, and
other traffic flows back up behind them.

FQ Fair Queuing
(single interface outbound queue)

(one packet at a time)

Fair Queuing is not an option on Cisco routers.

Allows packets that are ready to be transmitted to leave, even if
they started to arrive after another packet.
Complete packets that are ready to be transmitted leave first.
Remember, packets may enter the output buffer from a variety of input
interfaces.

Weighted fair queuing overview

Packet 3 is queued before packets 1 or
2 because packet 3 is a small packet in
a low-volume conversation
Small packet in low-volume conversation arrives 3rd

Weighted fair queuing (WFQ) is an automated method that provides fair

bandwidth allocation to all network traffic.
Provides traffic priority management that dynamically sorts traffic into
conversations, or flows.
Then breaks up a stream of packets within each conversation to ensure that
bandwidth is shared fairly between individual conversations.
There are four types of weighted fair queuing:
Flow-based Default (WFQ)
Distributed - Runs on Versatile Interface Processor (not discussed)
Class-based Next section
Distributed class-based (Not discussed)

Weighted fair queuing overview

(single interface outbound queue)

(one packet at a time)

Flow Based WFQ schedules delay-sensitive traffic to the front of a queue

to reduce response time, and also shares the remaining bandwidth fairly
among high-bandwidth flows.
By breaking up packet trains, WFQ assures that:
Low-volume traffic is transferred in a timely fashion.
Gives low-volume traffic, such as Telnet sessions, priority over highvolume traffic, such as File Transfer Protocol (FTP) sessions.
Gives concurrent file transfers balanced use of link capacity.
Automatically adapts to changing network traffic conditions.

Weighted fair queuing overview

T1

T3

WFQ default on T1/E1

and slower.
FIFO default on faster
than T1/E1.

Weighted fair queuing is enabled by default for physical

interfaces whose bandwidth is less than or equal to T1/E1,
or 1.544 Mbps/2.048 Mbps.

Weighted fair queuing operation

Packet 3 is queued before packets 1 or
2 because packet 3 is a small packet in
a low-volume conversation
Small packet in low-volume conversation arrives 3rd

The WFQ sorting of traffic into flows is based on packet header

addressing.
Common conversation discriminators are as follows (based on a
hash):
Source/destination network address
Source/destination Media Access Control (MAC) address
Source/destination port or socket numbers
Frame Relay data-link connection identifier (DLCI) value
Quality of service/type of service (QoS/ToS) value
The router determines what the actual flows are, not the
administrator.

Weighted fair queuing operation

WFQ assigns a weight to each flow.

Lower weights are served first.

Small, low-volume packets are given priority over large, highvolume conversation packets.
Flow Based WFQ algorithm allocates a separate queue for each
conversation.

WFQ is IP Precedence-aware.
This is only pertinent if the IP precedence bit is used
Coming next

Weighted fair queuing

(single interface outbound queue)
Flow #1
Flow #2

Flow #3
17

15 14

10

(relative time of arrival)

WFQ starts by sorting traffic that arrives on an egress interface into conversation flows.

The router determines what the actual flows are

The administrator cannot influence this decision.
Conversations are based on a hash (combination) of:
Source/destination network address
Source/destination Media Access Control (MAC) address
Source/destination port or socket numbers
Frame Relay data-link connection identifier (DLCI) value
Quality of service/type of service (QoS/ToS) value

Weighted fair
queuing

IP ToS bits are used to determine

which packet gets priority.
Simplification:
Dispatch = Finish time x Weight
Weight = 32768/(IP Prec + 1)

IP Precedence

Weight 12.0(5)T and later

Our Value

32768

16384

10920

8192

6552

5456

4680

4096

Weighted fair queuing

(single interface outbound queue, IP Prec Our Value)
Flow #1

0-8

Flow #2

3-5

Flow #3

0-8
17

15 14

10

(relative time of arrival)

FIFO Largest first, then medium, then smallest

FQ Smallest first, then medium, then largest
WFQ Multiplier is used, weight = 32768/(IP Prec + 1)
To keep it simple we will use our values and leave out some
details.
Lowest value wins!
Higher IP Precedence gets a lower value (weight)

Weighted fair queuing

(single interface outbound queue, IP Prec Our Value)
Flow #1

0-8

Flow #2

3-5

Flow #3

0-8
17

15 14

0-8

10

(relative time of arrival)

Dispatch = Finish time x Our Value (weight)

First packet: 17 x 8 = 136
Last
Lowest wins!
Second packet: 15 x 5 = 75
Lowest
Third packet: 14 x 8 = 112
Next lowest

0-8

3-5

Weighted fair queuing

(single interface outbound queue, IP Prec Our Value)

Flow #1

0-8

Flow #2

3-5

Flow #3

3-5
20

3-5

0-8

0-8

3-5

0-8
17

15 14

10

(relative time of arrival)

Must wait for previous

packet in flow to leave.
Handled using FIFO.
What if a flow has contains packets with different IP Precedence bits?
Problem is that high-priority packet, 3-5, cannot be dispatched until after the large packet in front of it

(same flow) leaves.

Packets within a flow are handled FIFO.

FYI
Configuring
weighted
fair queuing

I have more than 128

packets! No more come
into this queue.

Router(config-if)#fair-queue {congestive-discard-threshold}

The congestive-discard-threshold is the number of messages to

queue for high-volume traffic.
In other words, the maximum number of packets in a conversation held
in a queue before they are discarded.
1 to 512
Default is 64 packets.

FYI
Configuring
weighted
fair queuing

I have more than 128

packets! No more come
into this queue until .

The congestive-discard-threshold applies only to high volume

conversations that have more than one message in the queue.
The discard policy tries to control conversations that would monopolize
the link.
If an individual conversation queue contains more messages than the
congestive discard threshold, that conversation will not have any new
messages queued until that queues content drops below one-fourth of
the congestive discard value.

FYI
Configuring
weighted
fair queuing

I have more than 128 packets! No

more get into this queue until it has
less than 32.

Conversations cannot have any new messages queued until that

queues content drops below one-fourth of the congestive discard

value.
If a conversation queue exceeds 128 packets, the queue must contain
fewer than 32 entries (1/4 of 128) before allowing any new messages to
be queued.

Class-Based Weighted Fair

Queuing

Class Based WFQ

(single interface outbound queue, IP Prec Our Value)

Flow #1

0-8

Flow #2

3-5

Flow #3

3-5
20

3-5

15 14

0-8

3-5

WFQ

0-8
17

0-8

10

(relative time of arrival)

WFQ separates packets into flows and applies a weight to high-priority

packets so they can leave first.
CBWFQ adds a level of administrator control to WFQ.
The same WFQ process is followed, the difference is that the
administrator can control how packets are divided into the
conversation or flows.

Class Based WFQ

(single interface outbound queue, IP Prec Our Value)

Flow #1

0-8

Flow #2

3-5

3-5

Flow #3

3-5

0-8

20

17

15 14

CBWFQ
0-8
3-5
10

0-8
0-8

3-5
0-8

3-5
3-5

WFQ

(relative time of arrival)

Scenario: the administrator has decided that all high-priority traffic

should reside in the same flow, regardless of any other conditions that
might place them into separate flows, such as Source/destination
network address, Source/destination Media Access Control (MAC)
address, etc.
The WFQ algorithm is still at work, but the queue definition is now
under control.
CBWFQ can be used to guarantee that flows receive adequate
bandwidth defined by the administrator.

Class-based weighted fair queuing

overview

Class-based weighted fair queuing (CBWFQ) extends the standard

WFQ functionality to provide support for user-defined traffic
classes.
By using CBWFQ, network managers can define traffic classes
based on several match criteria, including:
Protocols
Access Control Lists (ACLs)
Input interfaces

CBWFQ

FIFO Queues

A FIFO queue is reserved for each class, and traffic belonging to a

class is directed to the queue for that class.
More than one IP flow, or conversation", can belong to a class.
Once a class has been defined according to its match criteria, the
characteristics can be assigned to the class.
To characterize a class:
assign the bandwidth
maximum packet limit
The bandwidth assigned to a class is the guaranteed bandwidth given
to the class during congestion.

CBWFQ

Router(config)# policy-map policy1

Router(config-pmap)# class class1
Router(config-pmap-c)# bandwidth 64
Router(config-pmap-c)# queue-limit 30
Router(config-pmap-c)# exit
Router(config-pmap)# class class2
Router(config-pmap-c)# bandwidth 128
Router(config-pmap-c)# exit

Class
3

1 2

Highest BW
Lowest weight
Highest priority
Bandwidth is configured in the policymap class (later)

CBWFQ (not you) assigns a weight to each configured class instead of each
flow.
Weight is proportional to the bandwidth (you) configured for each class.
Weight is equal to the interface bandwidth divided by the class bandwidth or
can be configured as a percentage.
Weight = Interface bandwidth / class bandwidth
32 = 2,048 kbps / 64 kbps (2,048 kbps = 2 Mbps)
16 = 2,048 kbps / 128 kbps
64 = 2,048 kbps / 32 kbps
A class with a higher bandwidth value will have a lower weight

CBWFQ

Class
3

1 2

Highest BW
Lowest weight
Highest priority

By default, the total amount of bandwidth allocated for all classes must
not exceed 75 percent of the available bandwidth on the interface.
The other 25 percent is used for control and routing traffic.
This is why when you configure a T1 link (and slower), you only get
75% of the bandwidth, unless you turn off queuing.

CBWFQ

Class
3

1 2

Highest BW
Lowest weight
Highest priority

The queue limit must also be specified for the class.

The maximum number of packets allowed to accumulate in the queue
for the class.
After limit is met packets are dropped see Tail Drop and WRED.
Packets belonging to a class are subject to the bandwidth and queue limits that
are configured for the class.
Router(config)# policy-map policy1
Router(config-pmap)# class class1
Router(config-pmap-c)# bandwidth 64
Router(config-pmap-c)# queue-limit 30

CBWFQ versus flow-based WFQ

Class
3

1 2

Highest BW
Lowest weight
Highest priority

Bandwidth allocation CBWFQ allows the administrator

to specify the exact amount of bandwidth to be allocated
for a specific class of traffic.
Up to 64 classes, and can control distribution among
them.

CBWFQ and tail

drops

Hey, these packets are coming in

faster than I can send them out!
For now I will store some of them
in my output buffer.

Packet bursts or flows demanding high bandwidth can cause

congestion when packets arrive at an output port faster than they can
be transmitted.
The router tries to handle short-term congestions by packet
buffering.
Packet buffering has a cost of delay and jitter, but the packets are
not dropped.
Jitter Any distortion of a signal or image caused by poor
synchronization.

CBWFQ and tail

drops

Now there are more packets than I can store

in my output buffer and I cant send them out
fast enough. Guess, I have to start dropping
later packets until I have room in my buffer.

Full

For network traffic causing longer-term congestion, a router using

CBWFQ or any of several other queuing methods will need to
drop some packets.
A traditional strategy is tail drop.

CBWFQ and tail

drops

Now there are more packets than I can store

in my output buffer and I cant send them out
fast enough. Guess, I have to start dropping
later packets until I have room in my buffer.

Full

Tail drop.
A router simply discards any packet that arrives at the tail end
of a queue that has completely used up its packet-holding
resources.
Default queuing response to congestion.
Tail drop treats all traffic equally and does not differentiate between
classes of service.

CBWFQ and
tail drops

I didnt receive an ACK for my last several TCP

segments. TCP says I have to go into slow start and
change my window size to 512 bytes. I can then
begin to increase it exponentially until I reach the
receivers advertised window size.

All TCP hosts with nonACKed segments go

into TCP Slow Start.

Full
Now, there is very
little traffic that
needs to be sent
out that interface.

When using tail drop, the router drops all traffic that exceeds the queue
limit.
Many TCP sessions then simultaneously go into a slow start.
This reduces the TCP window size.
Consequently, traffic temporarily slows as much as possible.
As congestion is reduced, window sizes begin to increase in
response to the available bandwidth.

CBWFQ and tail drops

Tail Drops

Full

Time

Queue
overused

Queue
underused

1. Traffic flows
enter the queue
at different
times

2. When aggregate
3. Under use causes
load exceeds queue
synched TCP window
Tail drops cause
expansion.
synched TCP window
reduction.

4. This causes more

Tail drop and window
size oscillations.
Bandwidth overused
then underused.

This activity creates a condition called global synchronization.

Global synchronization manifests when:
Multiple TCP hosts reduce their transmission rates in response to
packet dropping, and then increase their transmission rates after the
congestion is reduced.
The most important point is that the waves of transmission known as global
synchronization will result in significant link under-utilization.

TCP Slow Start and Congestion Avoidance

TCP Slow Start and Congestion avoidance are important issues in

networking.
For more information on these topics, please see:
TCP Performance
by Geoff Huston, Telstra
http://www.cisco.com/en/US/about/ac123/ac147/ac174/ac196/about
_cisco_ipj_archive_article09186a00800c8417.html
TCP/IP Illustrated, Vol. 1 W. Richard Stevens Addison-Wesley Pub Co
ISBN: 0201633469
IP Quality of Service, Cisco Press

Weighted Random Early Detect (WRED)

My buffer is not full, but I am going to use Random Early
Detection (RED) and start dropping some packets. This will
help keep global synchronization of TCP slow start from
happening.

Tail drops are a passive queue management mechanism.

Random Early Detection (RED) and Weighted RED are alternatives to tail
drops for CBWFQ.
Active queue management mechanisms (RED and WRED) drop packets
before congestion occurs.
This is to prevent tail drops and the ups and downs from global TCP
synchronization.

Weighted Random Early Detect (WRED)

My buffer is not full, but I am going to use Weighted
Random Early Detection (WRED) and start dropping some
packets. I will use a profile and average queue size to
determine what gets dropped.

WRED extends RED functions by permitting more granular RED drop

profiles for different types of traffic.
WRED combines RED with IP precedence values or with
differentiated services code point (DSCP) values.
Before tail drops are required, the router can drop packets based on
these IP precedence values.

Weighted Random Early Detect (WRED)

The WRED algorithm is constantly updated with the

calculated average queue size, which is based on the
recent history of queue sizes.

WRED

The configured WRED profiles define the dropping thresholds.

When a packet arrives at the output queue, the IP Precedence of the
ToS or the Differentiated Services Code Point (DSCP) value is used to
select the correct WRED profile for the packet.
The packet is then passed to WRED to perform a drop or queue
decision.

WRED

Based on the profile and the average queue size, WRED calculates
the probability for dropping the current packet and either drops it or
passes it to the output queue.
If the queue is already full, the packet is tail-dropped.
Otherwise, it is eventually sent out on the interface.
WRED monitors the average queue depth in the router and determines
when to begin packet drops based on the queue depth.
When the average queue depth crosses the user-specified
minimum threshold, WRED begins to drop both TCP and UDP
packets with a certain probability.

WRED

The packet drop probability is based on the minimum threshold, maximum

threshold, and mark probability denominator.
When the average queue depth is above the minimum threshold, RED starts dropping
packets.
The rate of packet drop increases linearly as the average queue size increases until
the average queue size reaches the maximum threshold.
The mark probability denominator is the fraction of packets dropped when the
average queue depth is at the maximum threshold.
For example, if the denominator is 512, one out of every 512 packets is dropped
when the average queue is at the maximum threshold.
When the average queue size is above the maximum threshold, all packets are
dropped.

WRED

If the average queue depth ever crosses the user-specified maximum

threshold, then WRED reverts to tail drop, and all incoming packets
might be dropped.
The idea behind using WRED is to maintain the queue depth at a
level somewhere between the minimum and maximum thresholds,
and to implement different drop policies for different classes of
traffic.
WRED is only useful when the bulk of the traffic is TCP traffic.
With TCP, dropped packets indicate congestion, so the packet
source reduces its transmission rate.

CBWFQ Using WRED Packet Drop

Example

In the following example, the class map class1 is created and defined

to use the input interface FastEthernet0/1 as a match criterion to

determine if packets belong to the class.
Next, the policy map policy1 is defined to contain policy specification for
class1, which is configured for WRED packet drop.

Router(config)# class-map class1

Router(config-cmap)# match input-interface FastEthernet0/1
Router(config)# policy-map policy1
Router(config-pmap)# class class1
Router(config-pmap-c)# bandwidth 1000
Router(config-pmap-c)# random-detect

Amount of bandwidth in
proportion of the link.
Weight = int bw/ class bw

Enables WRED

Router(config)# interface serial0/0

Router(config-if)# service-policy output policy1

Low Latency Queuing (LLQ)

The Low Latency Queuing (LLQ) feature provides strict priority queuing for

class-based weighted fair queuing (CBWFQ), reducing jitter in voice

conversations.
Configured by the priority command, strict priority queuing gives delaysensitive data, such as voice, preferential treatment over other traffic.
With this feature, delay-sensitive data is sent first, before packets in other
queues are treated.
LLQ is also referred to as priority queuing/class-based weighted fair
queuing (PQ/CBWFQ) because it is a combination of the two techniques.

LLQ

CBWFQ (without PQ, non-LLQ)), the weight for a packet belonging to

a specific class is derived from the bandwidth assigned to the class
during configuration.
The bandwidth assigned to the packets of a class determines the
order in which packets are sent.
All packets are serviced equally, based on weight.
No class of packets may be granted strict priority.
This scheme poses problems for voice and video traffic that is largely
intolerant of delay, especially variation in delay.

LLQ
No
RED/WRED

In the event of congestion or when bandwidth has expired, priority is

used to drop packets.
Voice traffic queued to the priority queue is UDP-based and,
therefore, not adaptive to the early packet drop characteristic of
WRED.
Because WRED is ineffective, you cannot use the WRED randomdetect command with the priority command.

LLQ

Although it is possible to enqueue various types of real-time traffic to

the strict priority queue, Cisco recommends that only voice traffic
be directed to it.

Configuring LLQ

and

When the priority command is specified for a class, it uses a

bandwidth argument that gives maximum bandwidth in kilobits per

second (kbps).
This parameter is used to specify the maximum amount of bandwidth
allocated for packets belonging to the class configured with the
priority command (during times of congestion).
The bandwidth parameter guarantees bandwidth to the priority class
and restrains the flow of packets from the priority class.
Note: There is also a max-reserved-bandwidth command that con
be used, so the priority queue does not starve the remaining queues.

LLQ Example
router(config)# access-list 102 permit udp host 10.10.10.10 host
10.10.10.20 range 16384 20000
router(config)# access-list 102 permit udp host 10.10.10.10 host
10.10.10.20 range 53000 56000
router(config)# class-map voice
router(config-cmap)# match access-group 102
router(config)# policy-map policy1
router(config-pmap)# class voice
router(config-pmap-c)# priority 50
router(config-pmap)# class bar
router(config-pmap-c)# bandwidth 20
router(config-pmap)# class class-default
router(config-pmap-c)# fair-queue

A strict priority queue

(with a guaranteed
allowed bandwidth of
50 kbps) is reserved
for traffic that is sent
from the source
address (10.10.10.10)
to the destination
address (10.10.10.20),
in the range of ports
16384 through 20000
and 53000 through
56000.

router(config)# interface atm1/0

router(config-subif)# pvc 0/102
router(config-subif-vc)# service-policy output policy1

Suggested Readings

Quality of Service (QoS)

CIS 187 Multilayer Switched Networks
CCNP
Rick Graziani
Spring 2009