Packet switching vs. circuit switchingCircuits as WAN connections battled successfully against packets for years because they guaranteed bandwidth, no matter what.
If you bought a T-1 circuit, the service provider nailed up 1.5Mbps from point A to point B, and that was your bandwidth come hell or high water.
Packets -- first frame relay then IP -- didn't do that. They shared the network capacity, and service providers typically oversold access lines, knowing that if all customers tried to use all the bandwidth they bought at the same time the network would be swamped. Everybody's traffic would suffer delays.
But frame relay service was relatively inexpensive compared with T-1s and it came in connections smaller than 1.5Mbps, usually in increments of 56Kbps. That meant sizing circuits to just handle demand, making business WANs more cost effective.
Plus frame relay services supported bursting -- the instant delivery of more bandwidth than customers contracted for to handle moments of spikes in traffic. Because the networks were oversubscribed, sometimes the bursts were available, sometimes not. But over time, they were available enough of the time to make the service attractive.
Frame relay also offered virtual circuits -- the logical carving up of access lines into lower bandwidth logical links tied to different sites. If a site needed connectivity to six others, it needed a single physical line subdivided into six virtual circuits. In the world of circuits, nothing was virtual. If one site in a corporate network needed to connect to six others, it needed six physical access lines.
As frame relay and later IP services matured, QoS was built into their standards so bandwidth could be guaranteed, just as it was in a circuit. That advance put packets over the top.
QoS vs. more bandwidthWhen 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.