How much QoS does a Residential End User Need?
Ken Camp talks about how SMBs–that’s Small Medium Businesses–are having to fend for themselves with regards to QoS. I’d say that applies to a typical end user too. Ken points out that certain software firewalls are offering QoS, which amounts to little more than bandwidth prioritization. I would argue that’s really all an SMB needs, or at least that is all they can realistically do.
Let’s look at what the QoS needs are for an SMB or a typical end user. QoS makes the assumption that there is more bandwidth than there is bits going across it and that those bits need to be prioritized to get an optimal experience. In my home network–and I’m a fairly advanced user–there is not a whole lot of traffic going across it. At times there are bursts of bandwdith usage, for example when I print or move a file from one machine to another. However that bandwidth is fairly isolated between machines not doing VoIP and I come nowhere near maxing out the capacity of my switches. It is my experience that SMBs have a similar usage profile, being nowhere near their maximum capacity in terms of network usage. Given the relatively limited resources of an SMB and the fact that implementing QoS there would be of limited value, it doesn’t make sense to waste the significant time and money it would take to implement it.
Let’s assume that, somehow, the SMB is able to max out their internal bandwidth and VoIP traffic degrades. I consider this highly unlikely, but let’s assume that we are able to do it somehow. The cheapest and most effective solution here is simple segmentation–put the VoIP traffic on a different set of physical switches. Only VoIP traffic goes through these switches and you would have to have a lot of VoIP calls going on in order to max out the available bandwidth. There will be some time and money spent to implement this, but it is very minimal and well within the capability of an SMB to handle (or at least get some help to handle).
The one place in the network where there is a potential for bandwidth contention is that narrowband pipe going to the Internet. Unfortunately, implementing QoS requires being able to control the connection end-to-end. Most SMBs and individuals are not going to be able to exercise much, if any, control over the other end of their Internet connection. That being said, there is one thing that can be done on the local end of the connection: prioritizing what gets sent over the connection.
As a brief digression, one thing people try and do frequently is prioritize what is being received over their Internet connection. This makes no sense. Where this really needs to happen is at the other end of the Internet connection–exactly where there is no end customer control. By the time the packet is received at the local gateway, the network that the packet will come into will very likely have more than ample bandwidth available–far more than is available on their narrowband Internet connection. As stated above, implementing QoS in this case would be of limited value at a high cost.
Prioritizing the upstream bandwidth to the ISP is the only practical thing that atypical SMB or end user can reasonably do to improve voice quality. True QoS requires end-to-end control, which clearly an individual or SMB cannot do in this case. By prioritizing and throttling that which leaves the local network out across the narrowband Internet connection, we can ensure certain types of traffic–namely VoIP traffic–goes first. This will give VoIP traffic a fighting chance of being “good” or at least “good enough.”
One issue with prioritization is that you need to know either what IP the traffic is coming from or what ports the traffic is using. When you use a hardware ATA or PBX, it’s relatively straightforward. You can simply prioritize traffic coming from those IPs. When you’re using a softphone like Gizmo Project, prioritizing by IP is not a great idea. In this case, you want to prioritize by service or port range.
This is where standards are wonderful. SIP uses well-defined ports and, in most cases, you can control what ports are being used by the SIP endpoint. Some of the more advanced firewalls can even identify SIP traffic by sight and prioritize accordingly. Skype, on the other hand, uses a proprietary protocol and is known to use a number of different methods to communicate. The thing that makes Skype hard to block on a network also makes Skype hard to perform QoS on.
I suppose something else an SMB can do is try to use different codecs for VoIP. All this will do is lower the bandwidth requirements needed for VoIP. G.711 is what people typically use if they have the bandwidth. If bandwidth is an issue, look at using G729a or iLBC.
