Category Archives: queuing

Traffic Shaping and Policing

Crash course in QoS

What is traffic shaping/policing? In a nutshell, policing is dropping packets when the traffic exceeds a certain speed threshold, while shaping is queuing the incoming traffic in order to send it at a lower rate. Naturally, shaping is applied to outbound traffic, while policing can be applied on both directions, although it is usually applied to the inbound traffic. The following is the general QoS terminology:

  • Tc – Time interval, over which the commited burst (Bc) can be sent
  • Bc – Commited burst, measured in bits. This is the amount of traffic to be sent each Tc.
  • Be – Excess burst in bits. This is the traffic sent above your Bc, and most of the time risks being dropped, due to being in excess
  • CIR – Commited information rate, in bits per second. This is you allowed speed from your Internet contract.
  • Shaping rate – This is the rate at which your device will be sending traffic, which may be equal to the CIR, or even a little bit greater (more on that – later)
  • Policing rate – The rate after which your ISP starts to drop your traffic, in order to control your speed (this may be bigger that the actual CIR)

The deal with Bc, Be and Tc is that if you have a 128kbps line, and the intervals are 10 in a second (that can be configured), each 10th of a second you send 12.8kb. If you don’t have anything to send one interval, you’ve wasted 12.8kb. So, to reclaim it, you could send 25.6kb the next interval, but now you’ve overused your allowance. That means that your Tc is 0.1, your Bc is 12.8, and when you reclaimed your lost bandwidth, your Be was 12.8kb.

As I mentioned, the time interval Tc can be configured. The time interval directly impacts your Be burst. Why would you modify your time interval, when you can burst all the traffic up as fast as you can, then just wait ‘in silence’ for the current time interval to end?

Consider you have a 32kbps serial line from your ISP. Which means that you can transfer 32 kilobits per second. However, what if the clock rate on your router is running with clock rate 64000? That means that the router is transmitting at the hardware speed of 64 kilobits per second. Does mean that we get twice the bandwidth allotted for free? No. Our device, as the DTE end of the line, cannot change the physical speed of transmission. Then how do we maintain the 32kbps speed? Simple – we transmit the most we can, and then wait. Since we can transmit 64kilobits per second, then we can transmit 32kilobits per half a second, and then wait another half of the second.

The VoIP guys now scream in terror “500ms latency?”. Yeah, it’s no good – we need the use of a shaper in such case.

Shapers

Using a traffic shaper (usually) means transmitting at a lower rate that receiving. There are a couple of gotchas to traffic shaping, mainly which traffic should you send first, and which one should wait in line, as well as the speed you are transmitting with. The first problem is resolved through queuing strategies.  The second – using careful planning of your shaping configuration. So let’s dive in!

We already established that if no shaping is used, our router will transmit at the physical clock rate as much as possible, and when your limit is reached (in our former case – at the half of a second), the ISP will drop police any other traffic for the rest of the interval (again, in our former case – for the rest of the half second). This 500ms latency is most of the time unacceptable, so we employ shaping. To assume a safe figure of many intervals in a single second (in order to minimize delay), Cisco routers have a predefined limit of the Bc value. How does the Bc affect your Tc? To calculate your Tc time interval, use the following formula

Tc = (Bc / CIR) x 1000

By default, Cisco routers will use a value of 8000 bits for Bc if the interface bandwidth rate <= 320kbps; and calculates the Tc using the upper formula (that’s why it is important to set up your bandwidth [speed] in the interface view). If your line is > 320kbps, your Tc will be 25ms fixed, and your Bc will equal = ( shaping rate * Tc ).

This setup ensures that delays are kept to a minimum, even with the default settings. Of course, you can tune your Bc, Be, CIR(using the bandwidth command), and by extension of the former values – the Tc (which cannot be directly modified).

Policing

Depending on the traffic contract with your ISP, your ISP may police your traffic with a Single rate or Dual rate policer. Single rate traffic contract usually defines an average speed, which the contractor guarantees. However, taking into account the “burstyness” of the traffic on packet-switched networks, and oversubscriptions, the contractor may decide to offer a Dual rate scenario. With the latter option, the contractor guarantees a minimum speed, and also provides a higher one, which is non-guaranteed.

One should also know that the policers are categorized into two groups: two-color and three-color. What that means is that the two-colored policer distinguishes traffic within the CIR, and traffic above it; while the three-color policer has the notions of two kinds of exceeding traffic – regular exceeding traffic, and extremely exceeding traffic (violating traffic). We can draw parallels with the Dual rate policer here – the CIR is the minimum speed guaranteed, which is the regular traffic speed for the policer. The non-guaranteed traffic is the regular exceeding traffic to the policer, and when traffic exceeds the average non-guaranteed limit, it is considered the violating traffic. Thus the policer has the notions of Conforming traffic, Exceeding traffic, and if three-colored, Violating traffic. As you can probably guess, the Dual-Rate policer can only be three-colored, as we have clearly defined minimum and average speeds. The way I like to differentiate between the single-rate and double-rate three-color policers is the following: it depends on the way we reserve bandwidth for the exceeding speeds. Let’s visualise it with some ASCII art! Here the higher rate “sits” on top of the minimum guaranteed rate.

Maximum "unsafe" utilization
|Be rate>===============
|Bc rate>

Maximum "safe" utilization
|Be rate>
|Bc rate>===============

No utilization
|Be rate>
|Bc rate>_______________

A peak in the midst of no utilization
|Be rate> /****\
|Bc rate>___/ *****\_____

A peak of violating traffic in the midst of no utilization
|Bv rate> /*\
|Be rate> /*** \
|Bc rate>___/ \_____

With a single-rate policer, whenever your traffic passes over the Bc rate, it will either get dropped, or get marked “eligible for discard”, which most of the time means that it will get dropped somewhere along the way if congestion occurs.

With each Tc interval, you gain the right to transmit Bc amount of traffic. If you transmit more than the Bc traffic, you get sanctioned.

With a double rate policer, whenever your traffic passes over the Bc rate, the Be rate is ‘utilized’. Each Tc interval you gain the right to transmit Bc+Be amounts of traffic. If your traffic is within the Bc rate, only the Bc ‘bucket’ is depleted. If you have stood a couple of intervals in silence, and then need to transmit, you could compensate for the previous ‘wasted’ time intervals, by filling in the Be bucket, thus getting a Bc+Be speed.

Summary

As one can see, the ISP limitations on speed are often rounded up to an interval of a second, which tends to get interesting to configure. Depending on what your goals are and which technology needs to be supported, an uplink traffic can be shaped in many ways. Fine tuning the shaping variables can either make wonders with your network, or make it as unresponsive as a dead cloud unicorn.

So, have you got anything peculiar to share on the QoS matter?

Advertisements

Queuing Mechanisms

While doing my studies for the CCIP certificastion, I’ll do a series of posts on Quality of Service. It is a matter that I’m not very familiart with, so by talking about it, I’ll be sure to learn it better, and hey – maybe somebody will find my explanations useful.

Today we talk about the possible queuing mechanisms.

  • Priority Queuing – Uses 4 queues. Always serves higher priority traffic first. May starvate(block) low priority traffic due to constant high-priority traffic getting serviced first.
  • Custom Queuing – Uses 16 static queues for traffic (+ queue number 0 for layer 2 control traffic). Includes Layer 2 headers into the PDU size. Sends frames from a queue, and adds the frame size to a counter until the counter size is bigger or equal to the queue threshold. If the counter is bigger than the threshold, the next time the queue starts from this additional value, instead of 0 (a.k.a. a penalty). The queue threshold is computed from the byte-count value (1500 default). The queue’s limit is the number of packets held in the memory of the router, before it starts dropping the inbound packets from the sender. If a lower priority queue has traffic to spare, higher priority queues can take advantage of it.
  • Weighted Fair Queuing – Uses flows (identified by source/destination address and port numbers, plus protocol type). Automatically schedules low-bandwidth, interactive traffic to the front of the queue, and never drops it from queuing1. The rest of the traffic is divided fairly between high-bandwidth flows. WFQ is enabled by default on all interfaces less than or equal to 2.048 Mbps (E1 line).
  • Class-based Weighted Fair Queuing – Classify traffic using class-maps, which can be handed a strict bandwidth, percentage, or the rest of the unclaimed by the other classess traffic (fair-queue). Each classmap can either use tail drop (default) or WRED (random-detect). The total amount of bandwidth allocated for all classes included in a policy map must not exceed 75 percent of the available bandwidth on the interface. The other 25 percent is used for control and routing traffic. (To override the 75 percent limitation, use the max-reserved bandwidth command.)
  • Low-Latency Queuing – brings strict Priority Queuing (PQ) to Class-Based Weighted Fair Queuing (CBWFQ), so that delay-sensitive traffic, such as data, can be serviced first, while the rest of the traffic is using CBWFQ. Set up by the priority [bandwidth] command line switch in policy-map->class-map view.