QoS, a discussion
Now, funny one this. QoS is really important, right? You’ll hear people say QoS enabled network this, gotta have Quality of Service for VoIP/Video solution that, otherwise it’ll fail.
Read this statement and remember… Quality of Service is meant to combat TEMPORARY network congestion.
As a whole, on a switched campus network with 100Mbps access ports and 1Gbps uplinks everywhere, it’s unlikely, though not impossible that you need QoS. QoS will be there to catch you every time you find a link congested. That’s all!
You could just have QoS misconfigured on your switches – like I did once, thanks to a telco provider I may have mentioned in the past. It meant the campus VoIP solution went in, every one did a dance, we thought that we had a VoIP solution running on a QoS enabled network, which was only a half truth. We had a VoIP solution. The QoS wasn’t configured correctly, but no one knew any different – seemingly the telco’s installation engineers didn’t either – till a few years down the line I viewed the configs to find that they were doing diddly squat in terms of prioritisation.
It didn’t really matter though right? We had enough bandwidth so that the devices on the switches could pass data all day and the interfaces never became congested enough for long enough to cause support calls due to quality, and if there were support calls generated, the call quality could probably be put down to one end being a call to a mobile or another external party.
So that’s all well and good if you’re staying on Campus. Instantly, the moment your voice call traffic is going off Campus, the game changes.
For the SWITCH exam, the remainder of this discussion is a little off-piste, we’re not talking about Routers here which but we may be talking about Multi Layer Switch SVI’s which are default gateways for networks and subsequently may need to consider things like global synchronisation and congestion upstream.
IT Management buy links from an ISP/Telco based on the perceived or measured need for the organisation in chunks of Mbps/Gbps because of prohibitive costing of said links. If all WAN links were the same price per Mb as a campus switchport, everyone would choose big link numbers, but they don’t.
So, importantly, these link sizing decisions are all driven or least heavily influenced by the commoditisation [sic] or lack of, Internet and private link bandwidth.
Because link bandwidth isn’t as cheap as your local switchport bandwidth, It’s very unlikely at this point that you’re going to say, right then, 1Gbps VPLS/MPLS links from all our offices please Mr ISP/Telco!
Notice I said MPLS/VPLS. You could buy xMbps/Gbps Internet links, but your traffic in transit will not be treated with any priority, so all the good work that you do as a result of this article will be for nothing the moment it’s traversing the Internet alongside little Billy’s uTorrent traffic for the latest World of WarCraft ISO rip.
So if you’re putting your inter-handset RTP traffic or SIP trunk traffic on a WAN link, to ensure your QoS model is extended to service that traffic in transit, you need to be on some sort of provider VPN, most likely, VPLS or MPLS.
It’s quite feasible to put your traffic out there on the Internet using a Site-to-Site VPN or an tunnelled Handset/Softphone remote worker to Call Server session, but there’s no guarantees, no SLA’s, if the call quality is dodgy or you have call connection issues, you have to learn to get over it. It totally depends on your requirements and expectations.