Quality+of+Service

The IP, Frame Relay, LAN trunking and ATM headers all contain fields for marking QoS bits.toc

=IP Precedence and DSCP=

The IP header contains 1 byte ToS field used for QoS. This is further subdivided, with the high-order 3 bits called the //**IP Precedence**//.

The following is a list of IP Precedence values:

IPP was later replaced when the ToS field was renamed the Differentiated Services Field and bytes 0-5 were replaced as the //**Differentiated Services Code Point (DSCP)**//. The low-order remaining two bits are for used with the Explicit Congestion Notification feature.

A DSCP value of 46 is referred to as //**Expedited Forwarding**//. This means that packets should be given queuing priority so they experience minimal latency but should be policed to prevent them from taking over a link. These suggested settings and associated behaviors are referred to as //**Per-Hop Behaviors (PHB)**//.

Class Selector
Since IPP and DSCP overlap, a set of PHBs were defined to allow backwards compatibility for routers that still only look for IPP.

Assured Forwarding
The AF PHB defines four queueing classes, along with 3 levels of drop probability inside each queue. To define this, 12 DSCP values are allocated in the format AFxy where X implies the queue and y implies the drop probability. The higher the value of X, the better treatment the packet should receive. The higher the value of Y, the most likely the packet is to be dropped within that queue.

=Non-IP Header QoS Fields=

Ethernet LAN
The ethernet header includes a 3-bit ToS field that only exists in addition to a trunking header (802.1Q or ISL).

WAN
Frame Relay and ATM headers provide a 1-bit field for QoS called the Discard Eligible bit in Frame Relay and ATM Cell Loss Priority in ATM.

MPLS provides a 3-bit field used for QoS called the MPLS Experimental Bit

=Locations to apply QoS=

Since the non-IP header fields exist on in certain locations, you may need to examine IPP or DSCP fields and apply the values to other areas for QoS. The following general rules apply:


 * **Classification**: Should occur at ingress only, and only on an interface that supports that type of header field.
 * **Marking**: On egress only, and only on an interface that supports that type of header field



=Modular QoS CLI=

Cisco introduced the Modular QoS CLI to make configuring QoS easier. MQC based tools usually being with Class-Based. The CLI is separated into 3 major commands:


 * The //**class-map**// commands defines the matching parameters for classifying packets into service classes
 * The PHB actions (Marking, queuing) are defined with the //**policy-map**// command
 * Finally, the policy can be applied to an interface with the //**service-policy**// command



=Classification using class-map=


 * Class-map names are case sensitive
 * the //**match protocol**// command means that IOS will use Network Based Application Recognition (NBAR)
 * //**match any**// will match all packets
 * Up to four CoS/IPP and eight DSCP values can be matched on a single //**match cos**//, //**match precedence**// or //**match dscp**// command
 * Class maps can be nested within each other
 * If there are multiple match statements, the //**match-any**// or match-all (default) option on the class-map command will decide which logic to use

=Classification using NBAR=

Also called deep packet inspection, NBAR can identify packets based on the URL, MIME or HTTP header. Depending on the protocol, NBAR can also determine information form application specific fields as well.

Another feature of NBAR is that it's libraries can be upgraded without upgrading IOS itself. This is done by copying the Packet Description Language Modules (PDLM) to flash memory and adding //**#ip nbar pdlm **// to the configuration.

=Class based marking configuration=


 * Requires that CEF is enabled (#ip cef)
 * Operates similar to how route maps work, in that matches are processes sequentially and once matched, not evaluated again.
 * Packets that are not explicitly matched are considered to match class-default class
 * Class maps are referenced within the Policy Map, and the policy map is applied to an interface



Normally, the following rules apply to CB marking


 * Mark as close to the ingress point of the packet as possible



=Marking using policers=

Policers measure the traffic rate in or out of an interface and determine if that traffic has exceeded the contract assigned to it. There are two components:


 * 1) Traffic rate in bits/second
 * 2) Burst Size in bytes

If traffic is within the contract, it is considered conforming. If the rate or burst rate is outside the contact, it is exceeding.

=Software vs Hardware Queues=

Software queues are those that are created on the inerfaces by the tools configured in IOS. When a packet leaves the software queue, its enters a small hardware FIFO queue. This final hardware queue is called the Transmit Queue. Hardware queues cannot be controlled by IOS, but when a software queuing tool is present, the HW queue automatically shrinks. This ensures that more packets are in the software queue and IOS has better influence over them.

=Queuing Tools=

FIFO Queuing
Since IOS defaults to using WFQ on interfaces, to enabled FIFO queuing, you simply must disable WFQ and any other queuing tools on the interface. The only useful settings for FIFO queuing is to set the size with //**#hold-queue <#> out**//, which is an interface subcommand.

WFQ is disabled with //**#no fair-queue**//

**Priority Queuing**
Consists of 4 queues: High, Medium, Normal and Low. Higher levels queues are always services first. The logic works like the following:



The only downside to priority queuing is that the lower levels queues can experience starvation if the higher level queues have a consistant flow of traffic. PQ also uses tail-drop, which means that if a packet arrives for a full queue, that packet is dropped instead of being serviced.

Custom Queuing
Has 16 different queues, and addresses the problems of PQ by ensuring a minimum amount of bandwidth for each. There is also a hidden system queue for important overhead traffic that cannot be configured or disabled. The downside to CQ is that there is no high-priority queue in which it services before the others, meaning you cant ensure that a certain subset of traffic has low latency. CQ defines a count of bytes that should be removed from each queue, and uses a round robin approach, removing packets from the queue until the defined byte count has been met or exceeded. This count is usually defined as a percentage of the interface bandwidth. The link percentage is calculated as (byte count for queue x/total byte count of all queues).

Weighted Fair Queuing
WFQ does not allow classification options to be configured. It consists of 4096 queues, with 8 overhead queues. The only allowed configurable queues are powers of 2. Each packet is automatically classified based on flows, with each flow being placed in a separate queue. For WFQ, a flow is defined as packets sharing the following:


 * Source IP Address
 * Destination IP Address
 * Transport Layer Protocol
 * TCP/UDP Source Port
 * TCP/UDP Destination Port
 * IP Precedence

The goals of WFQ are:


 * Flows with the same IPP should be given the same amount of bandwidth
 * Flows with higher IPP should be given more bandwidth
 * WFQ should favor low volume, high IPP packets

The calculate for IPP and bandwidth allocation is that flows with IPP 7 for example, get bandwidth proportional to IPP+1, or 8 times the bandwidth of IPP 0 in this case.

WFQ Scheduler
When WFQ wants to move the next packet into the HW queue, it takes the packet with the lowest Seq num. This Seq num is assigned to the packet when it enters the WFQ queue and is calculated via the following:

Previous SN + (weight * new_packet_length)

Weight is calculated as: 32,384 / (IPP +1)

WFQ Drop Policy
WFQ uses a two step process called modified tail drop. First, the absolute limit on the number of packets enqueued is considered. This is called the hold-queue limit. If a new packets arrives when the hold-queue limit has been reached, the packet is dropped. The second step is to consider the congestive discard threshold for the queue into which the packet is arriving. If the queue length is longer than the threshold, a packet is dropped. This packet isnt always the one arriving, as shown below:



WFQ Configuration
WFQ is on by default for E1 and slower links.



CBWFQ and LLQ
Both of these queuing tools use almost identical configuration, but are defined by the use of either the **bandwidth** (CBWFQ) command or the **priority** (LLQ) command. These support 64 queues, and the max queue length cannot be changed. However, the length will vary based on the router model and amount of memory installed. They both have a class-default queue, in which any non-matched packets are placed. CBWFQ can configure settings for the class-default queue.

CBWFQ Features and Configuration
CBWFQ ensures a minimum amount of bandwidth for each queue. Each queue is given a percentage of the links BW. If some queues are empty, the extra bandwidth is allocated across the other queues.

Defining and Limiting CBWFQ bandwidth
IOS checks to make sure CBWFQ doesn't allocated too much BW to the queues. The check is performed when the //**#service-policy output**// command is added to an interface. The command is rejected if too much BW is allocated. The BW allowed is based on two interface subcommands: //**#bandwidth**// and //**#max-reserved-bandwidth**//. To overcome this, its best to use the //**#bandwidth-percent**// command, which specifies a percentage of the //**#bandwidth**// command. You can also use //**#bandwidth-remaining-percent**// which is a percentage of bandwidth*max-reserved.



LLQ Features
For delay sensitive traffic, LLQ is usually the best option. It looks and acts just like CBWFQ, but it adds the ability to define some queues are low-latency. These queues are scheduled in the same way that PQ schedules the high-priority queue. It also uses a feature to prevent the queue starvation problem experienced by PQ. This is done by defining the bandwidth given to a LLQ as the guaranteed minimum and policed maximum.



The configurion is the same as CBWFQ, but an additional command is needed.

//** #priority { bandwidth-kbps | percent percentage } [ burst ] **//

Defining and Limiting LLQ bandwidth
Bandwidth is limited in the same manner as CBWFQ.



Misc - LLQ and CBWFQ

 * When multiple priority queues exist, LLQ places all packets from these queues into a single internal queue and treats them with FIFO logic.
 * Queuing logic is only used when congestion occurs. Congestion is occurring when the HW queue is full.
 * priority command is not allowed in class-default
 * If class-default does not have specified BW, most of the BW for this class is distributed among the other classes



Weighted Random Early Detection
Tail dropped can be an issue for TCP based network due to TCP slow start. WRED will monitors the queues and begin to discard packets before the queue fills hoping to slow congestion. WRED uses a metric called "average queue depth". This depth is then compared to a minimum and maximum threshold.

The difference between tail drop and full drop is that with a full drop, the queue might not actually be full when these discards occur. With the percentage drop, if the queue rises between the thresholds, the percentage of drops that occur grow in a linear fashion.

WRED uses a setting called the mark probability denominator, from which the maximum discard percentage of 10% is determined. The formular for the percentage is 1/MPD. When packets are discard in this way, they are randomly chosen from the queue.

WRED can give preference to packets with IPP or DSCP values set. To do this, WRED uses traffic profiles, which vary in the min/mix thresholds and MPD.

Some default values exist for these traffic profiles:

WRED Configuration
WRED can only be configured in the following:


 * A physical interface with FIFO queuing
 * A non-llq class inside of a CBWFQ policy map
 * An ATM VC

When enabled on a physical interface, WRED disables all other queuing mechanisms and enables a FIFO queue in which it mangages the drops. The //**#random-detect**// command is used to enable WRED. By default, WRED will use IPP markings only. To enabled WRED for DSCP, use //**#random-detect dscp-based**//.

To alter the traffic profiles for DSCP and IPP values the following commands can be used:

 //** #random-detect precedence precedence min-threshold max-threshold [ mark-probdenominator ] **// //** #random-detect dscp dscpvalue min-threshold max-threshold [ mark-probabilitydenominator ] **//

You can also configure the exponential weighting constant, which allows you to change how quickly the rolling average depth is calculated.

//**#random-detect exponential-weighting-constant exponent **//

=Switch queuing=

Cisco 3550 uses a single ingress queue in which to hold packets before being sent out the egress interface. The switches also have 4 egress queues with classification based on CoS and WRR scheduling.

The QoS decisions are based on an internal DSCP value that is assigned once the frame is forwarded. Once a frame has an internal DSCP value and is assigned to an interface, the following is used to determine the queue it is placed into:


 * 1) The frames internal DSCP value is compared to the global DSCP-to-CoS map to determine a CoS value
 * 2) The per-interface CoS-to-queue map determines the queue

The queues based weight on frames instead of bytes, and settings for each of the for queues are configured with

//**#wrr-queue bandiwdth 10 20 30 40**//

The fourth queue may also be treated as a priority queue, with the **#priority-queue out** interface subcommand.

The dscp-cos map is altered with: //**#mls qos map dscp-cos 60 61 62 63 to 1**// The cos-queue map is altered with: //**#wrr-queue cos-map **//

=**Switch congestion avoidance**=

The egress queues on a switch can use either tail drop or WRED for gigabit interfaces. Fast-ethernet interfaces use a cisco specific method of scheduling.

The details differ slightly from WRED on a router:


 * Each egress queue has two WRED thresholds
 * Thresholds are defined as a percentage of the queue length
 * Thresholds can be set differently for each queue on an interface
 * When the queue depth is below the threshold, packets are not dropped
 * When the threshold is exceeded, packets are dropped in a percentage of 0-100 with a linear growth rate.



The //**#wrr-queue dscp-map interface**// subcommand is used to configure the queue to dscp mappings. BY default, all 64 queues are mapped to threshold 1.

The //**#wrr-queue random-detect**// command on an interface enables WRED for all queues and disables tail-drop logic. If only one queue has this command then the other 3 queues still use WRED, but the thresholds are set to 100% so they basically just tail drop anyway. Thresholds are configured with the //**#wrr-queue threshold**// interface subcommand.