Queuing theory, as it relates to QoS, has remained fairly constant, consisting primarily of scheduling algorithms like Weighted Round Robin, and Weighted Fair Queuing, and Class-Based Weighted Fair Queuing, and Priority Queuing, etc. However, if you've ever actually tried to implement QoS, you probably noticed a couple of things. First, the sexy features you want to use are often implemented only on certain models of routers and switches, or certain interface types, leaving you with a choice of upgrading to a different model, or modifying your QoS strategy. And second, early implementations of QoS left a lot to be desired.
If you're planning a QoS strategy now, do your homework and be sure you understand the capabilities of your specific models of switches and routers and exactly what is supported in their software versions. For instance, you will likely find that your vendor's layer 3 switches and regular routers behave very differently when it comes to both marking and scheduling. If you were an early adopter of layer 3 switches, their older ASICs probably don't support many options, and aren't upgradeable. Although slower, platforms that make decisions in software are much more flexible and easily upgraded.
Another thing to watch out for is different interfaces. For example, 10/100 Ethernet ports may have a completely different set of capabilities from the Gigabit Ethernet ports on the same switch.
But QoS features have come a long way recently.
Requires Free Membership to View
SearchUnifiedCommunications.com members gain immediate and unlimited access breaking industry news, expert advice on UC, technical guides, and more -- all at no cost. Join me on SearchUnifiedCommunications.com today!
Kate Gerwig, Editorial Director
So if you implemented QoS back in the dark ages, you should take a look at some of the new features. A good example of dramatic improvements is the recent change to the "bandwidth" and "priority" commands in Cisco's IOS. These commands only used to allow you to configure the Kb/s you wanted, but fixed amounts aren't particularly useful, especially on interfaces like PRIs where you can change bandwidth on the fly. So in IOS 12.0(7)T, Cisco added the "percent" option to the "bandwidth" command so you can specify a relative number.
That still leaves us with a good deal of risk, so we have to think very carefully about how much we allocate to each queue or we can easily create more problems than we solve. So in IOS 12.2(2)T, Cisco added the "remaining percent" command. This very helpful addition reduces the risk of a mistake by making the bandwidth you allocate a relative percentage of the available bandwidth.
Thomas Alexander Lancaster IV is a consultant and author with over ten years experience in the networking industry, focused on Internet infrastructure.
This was first published in November 2003