Notes
Chapter #1 – Class Models
We don’t need to guess which classes to use. There are several good models out there that we can use as a template, and adjust according to our needs. Cisco have a 4/5-class, 8-class, and 12-class model (they vary in details, depending on the age of the article).
If you don’t have QoS in your environment yet, it’s simplest to start with the 4/5-model, and then move to the next model as your network matures.
The 4/5-class model can use either 4 or 5 classes. In the 5-class version, the ‘critical’ class is broken into ‘signaling’ (for SIP, etc) and ‘critical. The 4-class model looks like this:
Class | Marking | Bandwidth |
---|---|---|
Rea-time | EF | 33% |
Signaling / Critical | CS3 | 7% |
Transactional | AF31 | 35% |
Best Effort | BE | 25% |
Chapter #2 – Queueing and Scheduling
One action is queueing. Each physical interface has several logical queues. Packets queue here while waiting to be sent. We can align queues with traffic classes, and treat them with different priorities.
The scheduler is the process that decides which queue is serviced next. For example, a very simple scheduler could use a round-robin method, where a packet is taken from each queue in turn. However, this doesn’t apply appropriate priorities to different queues.
A better way is Weighted Round-Robin, where queues still take turns, but more important queues are serviced more often. On a Cisco router, this is called Class-Based Weighted Fair Queueing (CBWFQ). This is good for general traffic, but not real-time traffic.
With Strict-Priority queueing, one queue is serviced straight-away whenever there are packets in it. This makes sure it gets the priority. However, this can lead to queue starvation, where other queues aren’t serviced enough. This is good for real-time traffic, but not general traffic.
Low-Latency Queueing (LLQ) is a hybrid between Strict-Priority and CBWFQ. This balances the best of both methods and is the recommended approach in most cases.
When a queue fills up, packets need to drop. This is a tail drop, as packets are dropped from the tail of the queue. To tune this, we can use drop probabilities. This introduces something like sub-classes to the AF classes. The drop probability can be low, medium, or high. Packets in a class with a high drop probability are dropped before other packets.
Chapter #3 – Policing and Shaping
QoS offers two rate-limiting tools; Policing and Shaping. They both have a rate limit set. Any traffic under this limit is conforming, and any traffic over this limit is non-conforming.
The difference is how they handle non-conforming traffic. A policer will drop non-confirming traffic (or take another action such as remarking). A shaper will buffer the packets in a queue to send them out when there’s more bandwidth available.
Small bursts over the rate-limit are usually allowed, making the rate-limiters a little bit ‘friendly’.
The warning is that rate-limiters don’t have a good effect on some traffic, such as real-time traffic. It drops or delays the delivery of these packets.
Chapter #4 – Congestion
One of QoS’ jobs is to avoid congestion when possible. One way it can do this is with TCP windowing.
When packets are sent with TCP, the receiver needs to send an acknowledgment (ACK). If the ACK doesn’t make it to the original sender, the original traffic is resent.
It’s slow to ACK each packet, so one ACK can be used for many packets. The number of packets that can be covered by one ACK is called the Window Size. If an ACK isn’t received, the traffic in that window needs to be resent, and the window size shrinks.
A smaller window effectively slows the sender down, as it needs to spend more time waiting for ACK messages, and less time sending.
QoS uses this when a queue starts filling up. It will drop a random packet or two, which forces the sender to slow down, which helps with congestion for a while. QoS will drop more packets the more full a queue is.
Command Summary
Command | Mode | Description |
class-map | configuration | Create/modify a QoS class |
match … | class-map config | Match criteria, such as DSCP markings |
policy-map | configuration | Create/modify a QoS policy |
priority percent … | policy-map config | Create a strict priority queue with bandwidth reservation |
bandwidth percent | policy-map config | Allocate bandwidth to a queue |
service-policy … | interface config | Apply a QoS policy to an interface (with a direction) |
police … | policy-map config | Create a policer (rate-limiter) |
shape average … | policy-map config | Create a shaper (rate-limiter) |