Understanding all the theory behind how QoS parameters let you prioritise traffic is all very well, but you have to know where to implement the different pieces and what you’re trying to achieve. This article describes some deployment guidelines.
First off, (where) do you need QoS? Can’t you just throw bandwidth at the network? Well, perhaps, but bandwidth isn’t free and even with largely under-utilised links, there will come times when you have congestion, due to the inherently bursty nature of LANs.
QoS comes into effect where you have congestion - typically, at aggregation points (multiple user connections coming into a switch with one, albeit high speed, uplink) or points of speed mismatch. Applying QoS at these points lets your network deal with short-term over-subscription to prevent time-sensitive traffic from being unduly delayed, while slowing down other traffic, such as file transfers or email, that don’t mind an extra second or so response time.
And no, you can’t just use network devices with large buffers to cater for these periods of congestion. Storing everything causes delays and for some traffic types (including voice and some interactive data), if you delay the packets getting through, you might as well throw them away as they’re useless by the time they get to the far end.
High versus Low Priority
One thing to clarify: QoS constantly refers to high priority and low priority traffic. This is a misnomer and one that causes more problems than anything else. High priority traffic is not necessarily more important than low priority traffic (although it may well be). In QoS terms, it means that the traffic is more sensitive to delays, jitter and packet drops. You will find that the most difficult part of implementing a QoS-enabled network is the political part of getting the business to agree which traffic types should be classed as ‘higher’ priority than others. Talk about ‘time-criticality’ instead if you want to cut down on the emotive arguments.
What Goes Where?
You should classify and mark your packets as close to the edge of the network as possible - at the users’ PCs and on the servers, if possible. However, this necessitates the applications doing the marking and that setting being trusted throughout the network, which isn’t always either possible or a good idea.
So the wiring closet and server farm switches tend to be where packet marking is done, setting QoS values based on access lists to identify the different traffic classes you’ve grouped all your applications into.
You should pick a finite (three to five) number of traffic classes, with one for your strict priority traffic, one to three for the major data classes - perhaps transactional, streaming video and email, for instance, and one for everything else, that’s classed as best effort and will act as a catch-all for all the applications you don’t specifically match on. This also means that if a new application appears on your network, that the developers didn’t tell you about, it will get lowest priority, so won’t adversely impact the rest of your network traffic.
Prioritisation should then be configured on the access switches. You need to map your different classes into different queues according to the QoS value you have marked them with. This marking will stay with them now as they travel through the network, although layer 2 markings will have to be translated to layer 3 when you hit a subnet boundary. This is also where you would configure drop thresholds within each queue, so that in times of heavy congestion, you can manageably drop packets. You will likely find, for example, that you do not have one queue per QoS value, but may put COS 2 and 3 in one queue on a layer 2 switch and start dropping the packets marked 2 before those marked 3.
You may also want to police traffic out at the edge of the network, although often this isn’t done until you reach a WAN aggregation point. However, if you want to prevent users from flooding the LAN with games traffic, you can rate limit at the access port. This is also something that can be tied into Identity Management (802.1x), where, if you get clever, you can give users differing amounts of bandwidth depending on their login id; so that a network administrator gets a full 100Mbit/s link wherever they plug into the network, while a guest, or temporary contractor, is limited to 10Mbit/s. Rate limiting can be applied at the interface on traffic as a whole, or again using access lists, to restrict specific types of traffic.
Within the campus, then, you will typically have to configure classification and marking at the edge, prioritisation and congestion management, including WRED, throughout the LAN, and potentially policing. In the next article we’ll look at WAN specifics, including LLQ and optimisation schemes such as LFI and cRTP.