Quality of Service (QoS) on our LAN switches is often misunderstood. Now and then, people ask me why we need it since we have more than enough bandwidth. If we don’t have enough bandwidth it’s easier to add bandwidth than on our WAN links. If you use any real-time applications like Voice over IP on your networks then you should think about implementing QoS on your switches. Let me show you what could go wrong with our switches. Here’s an example:
Above, you see a computer connected to a switch with a gigabit interface. Between SW1 and SW2, there’s also a gigabit interface. Between SW2 and the server, there’s only a FastEthernet link. In the picture above, the computer is sending 400 Mbps of traffic toward the server. Of course, the FastEthernet link only has a bandwidth of 100 Mbps, so traffic will be dropped. Another example of traffic drops on our switches is something that might occur on Monday morning when all your users are logging in at the same time. Let me show you a picture:
In the example above, we have 3 computers connected to SW1, SW2, and SW3. These switches are connected to SW4. It’s Monday morning, and all users are connecting to the server to log in. The traffic rate for each computer is about 70 Mbps. 3x 70 Mbps = an aggregated traffic rate of 210 Mbps which is more than the Fa0/0 interface of SW4 can handle. As a result, the buffer will be full, and traffic is dropped. Is this a big problem that our traffic is dropped?
If this is a pure data network, it wouldn’t be much of a problem because most traffic is TCP based. We can do retransmissions, and besides that things are a bit slower it will work. If we use real-time applications like voice over IP or a video conference stream, we want to avoid this as it will directly impact the quality of our voice conversation or video stream.
In the Voice over IP world, we use a DSP (Digital Signal Processor) to convert analog audio to digital and vice versa. These DSPs can rebuild about 30ms of audio without noticing it. Normally we will use about 20ms of audio in a single packet, which means that only a single packet can be dropped, or our voice quality will be degraded.
It’s impossible to fix these problems just by adding more bandwidth. By adding more bandwidth, you can reduce how often congestion happens, but you can’t prevent it completely. Many data applications will try to consume as much bandwidth as possible, so if the aggregated traffic rate exceeds one of your uplink ports, you will see congestion.
By configuring QoS, we can tell our switches what traffic to prioritize in case of congestion. When congestion occurs, the switch will keep forwarding voice over IP traffic (up to a certain level that we configure) while our data traffic will be dropped.
In short, bandwidth is not a replacement for QoS. Using QoS, we can ensure that real-time applications keep working despite (temporarily) congestions.