Quality of Service (QoS) is a mechanism used to reserve bandwidth giving selected packets priority in a network, therefore ensuring a minimum level of performance for selected data flows. QoS can be very complex and difficult to implement in large networks. For the average consumer home network though, it’s rather simple. It’s simple because you can only realistically control outgoing QoS, or your side of the router. You can exert your will over packets leaving your network, but it’s up to your ISP as to how packets arrive. That begs the question. Do you really even need QoS? That depends.
QoS, the Basics
A little clarification before we go too far; Incoming is data coming from your ISP to your router. Outgoing is going from your router (or network) to your ISP. If you have a faster connection (>6Mbps up, at least 1Mbps down), and you don’t do a lot of bandwidth intensive activities you could probably do without QoS, incoming or outgoing, entirely. Conversely, if you have a very busy family, and on any given day somebody is pw3n1ng on Xbox Live, someone else is shopping online, and another person is watching HD videos on Hulu, outgoing QoS will probably help.
Incoming QoS on a consumer grade network is a lost cause. Like I said, you don’t really have any control over data coming from your ISP. By the time it gets to your router, it’s too late. For this reason it’s usually best to turn off inbound QoS entirely. Another reason to turn off inbound QoS is most routers aren’t smart enough to know how fast the connection to the ISP is. Because of this, you usually have to set the max bandwidth in the router. Due to variation in network speeds (especially with cable) you have to step your top speed down by 10 or even 20% depending on your ISP’s stability. So even if at any given moment your speed is pegged at 100%, the router will step it down to 80%, because it has no way of knowing data is flowing at full speed. So in this case you give up bandwidth. Also, if you set the max bandwidth too high (say at 100%), and you receive a phone call when your network is busy, and your incoming connection is at 80% capacity, the queue will fill up, the router will drop packets, and quality will degrade.
This works the same way with outgoing, but since you have control over this it’s worth losing up to 20 or so percent to ensure quality. DSL may be an exception due to it’s non sharing nature. If you have DSL you may be able to set your speed at 90 or even 95%. Take speed tests at different times of the day to get an idea of the consistency of your ISP.
On a side note, BitTorrent is another story. In my experience the best thing for BitTorrent is bandwidth throttling. Most BitTorrent clients allow you to limit bandwidth in the preferences. It’s especially important to limit your download rate. This will probably be your best choice to achieve some semblance of incoming quality of service. E.g. for a 10Mbps connection set the BitTorrent upload and download rates at 50% to leave plenty of room for web browsing and VoIP calls.
Configuring VOIP
Keep in mind I’m presenting the most basic way to configure VoIP QoS possible to keep it simple. There are several ways of classifying, or segregating your data for QoS. The two ways you’ll find in most consumer grade routers are MAC Address, and IP Address.
MAC Address
A MAC Address (Media ACcess Address) is a unique identifier assigned to most network devices whether it be a router, VoIP device, or your PlayStation. You can usually find it printed on the back of your device, or in the device setup.
IP Address
An address assigned to a network device for location purposes. Basically, the IP address is how the router knows where to send packets. You can usually find this information in your routers device list.
IP address is the easiest and quickest to set up. If your VoIP device does not have a static IP in your network then use Mac Address. Below is a screen shot of a typical setup with IP address using Tomato v1.25:
In the above figure there are only three fields that we’re concerned about. “From 192.168.1.150” which will apply to any data sourced from that IP address (in this case an ooma Hub). The class is set to highest since we want VoIP traffic to have priority. The protocol is set to “Any Protocol” (not shown) which will cover everything. If “Any Protocol” is not available use “TCP/UDP” since most VOIP protocols are transmitted over UDP.
QoS uses classes to prioritize in descending level of importance. Starting with the untouchable class, usually labeled “Highest” or “Exempt” down to “Low” or “Standard” depending on the router (or firmware). To keep it simple set the VoIP class to whatever the highest setting is. Conversely, set all other traffic to the lowest setting. If you have the option to set a default class, set it to the lowest priority class. Below is a screen shot of a basic setup again using tomato v1.25 firmware.
Here the outbound rate limit is set at 1000 kbit/s (or 1 Mbps), and the “Highest” class is set to reserve 30%, or 300 kbit/s for VoIP traffic. Whenever a call is made 300 kbit/s of bandwidth will be set aside for the call. The inbound limit is set to the highest value possible effectively disabling it.
A word on setting max bandwidth for QoS. If you’re not sure what number to set this to use trial and error to find a setting that will give you good call quality. Start with 95% of your advertised upload rate. If after a few days (or weeks) you notice call quality is not always good then try 90%, and repeat until call quality is acceptable. If you get to 70% and call quality still suffers then I would look at your ISP as a potential problem. In these cases a good VoIP test is your friend. Perform the tests located here and here multiple times a day, for a week or so, to see if you’re getting consistently bad results. If you do a call to your ISP to check your connection may be in order.
More Reading
My intent was to show how to setup QoS without overwhelming you with details. If you want to know more here are a few links from sources that were helpful to me:
I guess I’m a little confused, I have 20 meg down and 4-5 meg up. How would that equate to this setup? Using OOMA hub and GS with Tomato 1.25.
John
With that kind of bandwidth you probably don’t need QoS. Unless you’re having trouble with call quality I wouldn’t bother.
As for setting outgoing QoS the first question would be how stable is your connection? If you get 5mbps up pretty consistently I would set the max bandwidth to 90% (4500kbits). Then set “Highest” at 10% and “Low” at 10% to 100% and see what kind of quality you get.
Great info. Thanks for sharing!
Since you configured QoS on your router, did you disable QoS on your Ooma hub, or leave it at its default settings?
In your configuration above, you reserved 300kbit/s for the Ooma. I’m still learning about QoS, Tomato, and Ooma’s configuration/setup, so I wonder if additional bandwidth is available (not being monopolized by other network traffic), will the Ooma use more than 300kbit/s or is it also limited to that amount?
And if left in place, could Ooma’s default QoS configuration limit bandwidth for the Ooma? So assuming you router QoS configuration reserves at least 300 kbit/s for Ooma but will still allow Ooma to use more bandwidth if it is available, could Ooma hub’s default QoS configuration limit the bandwidth to whatever it is set at? If so, it would make sense to disable Ooma’s QoS (use “0″ for both download and upload).
I just bought an Ooma Telo and plan to install it behind my router and configure QoS on the router (I will be using a WRT54GL and latest version of Tomato). I assume Telo and Hub are similar for QoS configuration. Hopefully my questions make sense…
I would definitely disable QoS on the Hub (or Telo) if it’s enabled on the router. Also, the bandwidth to the ooma device will be limited by the QoS setting. It will not use more bandwidth if needed.
This configuration works for both the Telo and Hub. The router QoS is independent of the device. The router doesn’t care why it’s reserving (or limiting, depending on how you look at it) bandwidth, it just does what it’s told.
Good luck! Let me know if you have any more questions.
Just picking a tiny nit. There is some QoS that is possible on the inbound side using TCP congestion control. Basically what happens in a TCP session is that the sending side can’t simply throw out as many packets as it’s local network can handle, and expect everything to work. So there’s a mechanism w/in TCP that slows the sender down. This is to the sender’s benefit because if I’m downloading data from a website over a 56k modem, the sender will have to deal with a lot of packet retransmissions if it doesn’t slow itself down to a speed that I can handle. TCP has builtin features to handle this kind of thing.
It turns out that a router can manipulate inbound TCP streams so that it slows down all except the ones that it wants to give priority to.
But you’re right that it’s a lot easier to control outbound traffic than inbound.