QoS 101

Congestion, Delay, Jitter

Congestion occurs when there is more traffic to be sent than the interface can physically send. Depending on the configuration, packets that are waiting to be sent can be dropped or queued. Dropping is no good because the information is lost (UDP) or it may require retransmissions (TCP). Queuing on the other hand introduces delays. For some types of traffic this might not be a problem but for voice traffic this will result in poor quality. Another important factor is delay variation, called jitter. It will also have a negative impact on voice or real time traffic.

QoS Architectures: IntServ vs DiffServ

QoS tries to model the way network devices handle traffic in order to offer each application the required QOS level in terms of congestion, delay or jitter. When deploying QoS in a network, there are 2 models that can be used: DiffServ and IntServ.

IntServ

IntServ provides an Integrated Services model, where the sender application requests a QoS level from the network, and the network devices agree to offer the required level end-to-end, from the sender to the receiver. The routers will have to implement a signalling method to communicate with the sender and with each other in order to agree if such a service level can be delivered or not. The signalling protocol used for IntServ is RSVP (Resource Reservation Protocol).

DiffServ

DiffServ provides a Differentiated Service model, where each router along the path from sender to the receiver must be manually configured to offer the required QoS level for the application. There is no signalling protocol involved so routers and applications do not talk to each other. So how does one router know what the application level should be? The process of Classification will do that. Traffic will be separated into different classes and each class will be treated differently. Usually, traffic classification is performed at the network edge and then the traffic is marked according to the Type of Service that should be assigned to it. For each QoS marking a PHB (Per Hop Behaviour) is configured that defines the QoS level.

QoS process

Classification and Marking

See Classification and Marking

Congestion Management (Queuing)

Currently, the most used method of configuring QoS is via the MQC. See CBWFQ.

Before MQC, there were 4 types of Queuing mechanisms that could be used on an interface of a Cisco Router. They are known now as legacy methods of configuring QoS: FIFO, WFQ, PQ, CQ. See Legacy Congestion Management for more details.

Additionally, IP RTP Priority and IP RTP Reserve are ways of configuring a Priority Queue for RTP (usually voice) traffic.

Congestion Avoidance (WRED)

There are 2 methods for congestion avoidance: Tail Drop and (Weighted) Random Early Detection. See Congestion Avoidance – WRED for more details.

Policing and Shaping

See Policing and Shaping for more details.

CAR

CAR is a legacy mechanism that can perform classification, marking and policing. See CAR 101.

MQC (Modular QoS CLI)

MQC is a Cisco CLI Component used to apply QoS settings. In newer IOS versions, HQF is used instead of MQC. HQF is a an extended implementation of MQC that allows the use of hierarchical policies. They actually work pretty much the same.

There are 3 steps when using MQC:

Classification

R(config)# class-map CLASS [match-all | match-any]
!match-all = AND (default)
!match-any = OR

Now add match criteria for the class:

R(config-cmap)# match ATTRIBUTE VALUE

For details, see Classification using MQC.

Creating a Policy

A policy is a list of Classes and the actions defined for each class:

R(config)# policy-map POLICY
R(config-pmap)# class CLASS

Now, inside each class you can define the QoS parameters for Marking, CBWFQ for Congestion Management, Class-Based WRED for Congestion Avoidance, Policing or Shaping and so on. You can also define a service policy for a class, which will make use of HQF, thus making the current policy the parent of the policy defined in the service policy Here are some of the things you can define for each class:

R(config-pmap-c)#?
Policy-map class configuration commands:
  bandwidth        Bandwidth
  compression      Activate Compression
  drop             Drop all packets - used as a Security feature
  exit             Exit from class action configuration mode
  log              Log IPv4 and ARP packets - used as a Security feature
  netflow-sampler  NetFlow action
  no               Negate or set default values of a command
  police           Police
  priority         Strict Scheduling Priority for this Class
  queue-limit      Queue Max Threshold for Tail Drop
  random-detect    Enable Random Early Detection as drop policy
  service-policy   Configure Flow Next
  set              Set QoS values
  shape            Traffic Shaping

Default Class

In a policy, all traffic that is not matched by the defined classes will be considered to be inside the default class. This class can be configured using:

R(config-pmap)# class default-class

Applying the Policy on an interface

R(config-if)# service-policy {input | output } POLICY

Verifying

To verify the configuration, use one of the following commands:

R# show class-map 
R# show policy-map [POLICY class CLASS]
R# show policy-map interface INTERFACE

Compression and Fragmentation

See Header and Payload Compression, Link Fragmentation and Interleaving or look for Frame Relay Fragmentation Support.

Frame Relay QoS

Frame Relay offers some specific QoS configuration options which are detailed in the Frame Relay QoS article.