QoS pays off in the WAN, if not in the LAN.
Speedier Ethernet has pretty much satisfied LAN bandwidth needs, but QoS has come to the rescue in the WAN.
When a drain chronically runs slow even though it isn’t plugged, it’s time to get a bigger pipe.
That is pretty much the conventional wisdom about network connectivity – if links slow down, get bigger links.
That has proved to be a useful rule if you judge by the progress of Ethernet, for example. It started out slow at 10Mbps, then grew faster at 100Mbps, then 1Gbps and now 10Gbps with higher speeds coming into sight. As network traffic increased, networks slowed because of congestion, so businesses built faster networks.
The limiting factor has always been cost. If important enough traffic slows down enough, businesses invest in bigger bandwidth. Inevitably, as the latest, fastest technology matures, the price-per-port drops so it becomes affordable even to those who don’t need it.
QoS prioritizes traffic by type so the really important stuff gets the bandwidth it needs to cross the network unimpeded by the unimportant stuff. This can be done by queuing, dedicating bandwidth and rate-limiting low priority traffic.
Even if bandwidth is plentiful and congestion is unlikely, businesses may implement QoS anyway to make doubly sure that real-time traffic such as VoIP and IP video don’t get bogged down. But the hassle of implementing QoS on routers for no noticeable gain has many businesses ignoring it.
The story is different over the WAN where more bandwidth means bigger bills month after month. There’s no way to wait for a faster technology, buy it for lump sum and reap its benefits as in the LAN.
QoS to mete out bandwidth to the applications that require it becomes necessary if money is factored in. So this debate has a split decision: more bandwidth in the LAN and QoS in the WAN.
