Well,
technically, QoS isn't required. On a perfectly planned network, that limits user interactions, has no changes, and never has anybody move large stuff across links, QoS won't do anything. But it's also like saying that your car
technically does not need shocks, because you will never hit a pot-hole on your way to the office -- ever.
Under the hood, what QoS does is prioritize certain types of traffic (voice in our case). It is most useful when you run across links between switches where there is some sort of contention or congestion of traffic. If you build a network that is is 10G to each port, nobody streams anything, and the biggest user streams at 300k/s, it's pretty unlikely you need QoS, because your links just won't get saturated, so there's no contention, and no need for a router to put certain packets ahead of others. The danger runs where now you put in servers on that network that, let say backup to each-other -- send 100GB worth of data twice a day for 60 seconds.... Now in those two minutes, the traffic that needs to happen "right now" has to contend with this traffic that can be delayed a few seconds without impacting anything. On our imaginary network, lets add 400 users, who all want to stream an important event -- could be the NCAA final round of basketball, but for our example we will say the season finale of Days of our Lives. 400 users * 10MB/s = 4GB/s of background noise that your network is processing on top of your priority traffic -- and without QoS, the network will delay ALL traffic to process its queues, as it sees it as all important.
Dirty little secret -- at MSU, we don't run QoS across our phone network. We have an over-built network that is dedicated to phones. All the traffic is the same priority -- real-time, so in reality there isn't anything to prioritize over for voice traffic. If our links get saturated, it would be saturated with voice traffic, so there really isn't any use. Now, we do have some phone on our commodity data network, and QoS is required there (turns out, when you mix students, researchers, and the general community on a network, lots of fun things happen). Now, for the longest time, our network engineering group didn't implement QoS, and instead opted to just buy bigger routers, bigger links and bigger switches to keep up with the demand so they didn't need to do QoS -- but they finally accepted that they couldn't win the battle.
Now, there might be some new-fangled technology from the company that made the hardware that run's Cysco's network -- but the concept of QoS really should be though about in the architecture of a deployment. Whether your gear is looking for specific TOS or DiffServ values, VLAN tags, or self-identifying types of traffic to set priorities, it is still valuable in most cases. You do need to watch out, because that particular vendor has a habit of making these new technologies work only with their gear (at first), but putting on the spec sheets that it works with "every phone."
------------------------------
Nick Kwiatkowski
Michigan State University
------------------------------
Original Message:
Sent: 11-21-2019 06:20 PM
From: James Rawland
Subject: QoS
I am working a project and stressed the importance of QoS to the PM. They reportedly brought in the consultant from that no-one-ever-get-fired-for-buying-our-equipment company and were told that QoS was no longer needed. I've always considered that having QoS was one of the 10 Commands of the telephony world. Anybody else hearing the same thing and if so, is it true?
------------------------------
James
------------------------------