Does QoS for VoIP work?

Discussion in 'Tomato Firmware' started by jackie999, Apr 29, 2010.

  1. jackie999

    jackie999 Addicted to LI Member

    I've been reading and see so much conflicting data that I thought I'd ask here, where most research is available.
    I have and I do a little downloading. No gaming, no torrenting. Would setting up a a few QoS rules make any difference to phone calls? Now, when a call comes in I just pause my downloads, but automating it would be much nicer. Most of the examples are much more complicated than I need there one for my basic needs?
    Should I switch to DD-WRT and use the TCP vegas setting since it seems to work without to much technical knowledge - aka idiot proof :)
  2. rhester72

    rhester72 Network Guru Member

    TCP Vegas will have absolutely no effect. It only controls endpoint connections _initiated by the router_, which VoIP is most definitely not.

  3. Toastman

    Toastman Super Moderator Staff Member Member

    If, as you state, you do a little downloading, but nothing else in particular, then even some simple QOS rules might benefit you.

    The single most important thing you have to do to allow VOIP to work well is always make sure there is sufficient incoming bandwidth available. You can test this by enabling QOS, setting outgoing and incoming limits as per the usual recommendations (follow link below for info) - set your INCOMING maximum limit to 66% of your maximum incoming bandwidth from your ISP. This figure that has been measured and found to work well in most instances.

    That should immediately solve the VOIP problem but will also limit your download speed unless you set up QOS properly. And from hereon in, you're going to get steadily drawn into how to set up QOS - this really is something you have to do yourself, or copy someone elses' and adapt it if it doesn't do quite what you want, though.

    And Vegas is, as Rhester says, quite useless in this case - just ignore it.
  4. jackie999

    jackie999 Addicted to LI Member

    Thanks for the info..I will take it step by step then. I don't want to limit ALL of my download speed..lord knows it's not much to begin with :)
    I would love to copy someone elses', as you say. Until then, I'll keep reading...
  5. Porter

    Porter LI Guru Member

    It's probalby not even this complicated to help you skyping by only using the Tomato GUI.

    I'm assuming that you are the only user on your network.

    First you should make Skype use a specific port which then can be used to make an appropiate rule. You should probpably use something above 48000, although I keep forgetting the ranges that are freely available.

    Basically you only need two rules: one for Skype and one for the rest.

    In the chart on QoS/Classification the skype-rule always needs to be on top. Just make one with the High-setting, both protocols (tcp and udp) and your port you put Skype on (Src or Dst).

    The second rule is already there. It's the Bulk Traffic-rule which needs to be changed a bit though. Change the port span from 1024-65535 to 1-65535. Delete the other rules (I don't know how to restore those rules without making them yourself again, so you probably should backup your config before really changing it. That's generally a good idea...)

    Under QoS/Basic Settings you now need to put in your connection speed and hopefully you do know those numbers. You will have to do some testing, but a good starting point ist to not use 100% of your bandwidth but start with 65% and then increase it according to the amount of congestion that occurs.

    As far as my research went Skype needs around 128kbit in and out for _one_ telephone conversation. So 128kbit needs to be the minimum setting on High (Outbound).
    The rest of your bandwidth can be put on Lowest (Outbound)

    Under Inbound your High-Class again needs 128kbit and the rest of your bandwidth can be put on Lowest. This way you actually shape your downloads, which you didn't want, but that's the easiest way. The 128kbit you deducted from your whole connection won't be used if Skype isn't active. So you'r actually loosing some bandwidth. For many people that's ok, because 128kbit usually isn't much.
  6. jackie999

    jackie999 Addicted to LI Member

    Thanks for the guidelines uses port 5060 I believe..I'll take that into account and try setting up using your numbers.
  7. Toastman

    Toastman Super Moderator Staff Member Member

    Just a quick comment. Let's assume 128k sustained bandwidth is the requirement. However, if you set an incoming limit at this, you will shoot yourself in the foot. If there is a backlog, some of the stream is delayed in a bottleneck either at the ISP or somewhere on the web, then when this backlog "burst" arrives at the ISP it would need to be sent at a higher speed to your router to clear the backlog and avoid stutter. Since you've placed a limit on the speed, packets will likely be dropped instead of being delivered.
  8. Porter

    Porter LI Guru Member

    But what's the alternative? If you only need to prioritize one specific port/protocol this seems to be a reasonable solution by utilizing the GUI. Apart from that every inbound class gets a burst of 4% of its whole bandwidth. With 128kbit this gives a burst of 5kbit (if I'm not mistaken). This burst ist quite tiny and might not be sufficient, but you can either increase the 128kbit to maybe 160kbit (which probably is sufficient bandwidth even when there is a burst from your ISP so no drops should occur) with a burst of 6kbit or you edit /etc/qos by hand and put in a higher burst, probably 16 or 32kbit.
  9. fun.k

    fun.k Addicted to LI Member

    Hey guys, I'm trying to figure a similar QoS solution (no p2p/games) in Toastman's thread to maintain sanity.

    Porter, is skype working ok for you on it's own class, say a standard percentage to maintain 128Kbps in both directions?

  10. Porter

    Porter LI Guru Member

    First of all I need to tell you that I'm using my own script to do traffic shaping. Secondly I don't think I've already tested the script with Skype.

    I've seen your screenshots of your config and would like to point out that your inbound rates are too high because if there is traffic in all classes they will exceed your 16000KBit, because these rates are added together. To be on the safe side the sum of your inbound rates should not exceed 16000KBit. It may be usefull to limit the number of classes because then they can get a higher inbound limit. The problem I'm referring to might not even occur on a regular basis, so it might not be as harmfull to let your overall inbound rate be higher then 16000KBit which means that your classes get a higher inbound rate. Just wanted to mention it, because it might confuse you, if you don't keep that in mind.

    Furthermore you should start with only 65% of your 16000KBit and then find out how well this works when there is a lot of traffic.
  11. fun.k

    fun.k Addicted to LI Member

    Thanks for clearing that up Porter :)

    I probably got overwhelmed cause after a few tests in the last days the skype phone is behaving like a good old landline phone.

    Thanks again, gonna do some more reading.
  12. fun.k

    fun.k Addicted to LI Member

    Here's another observation while trying to set this straight. On the standalone skype phone, there're 2 settings available:


    Observing the QoS Details on Tomato, I see that the skype phone opens connections in other ports too. This is why I chose to have its rule identified by its IP/MAC address instead of the chosen Source/Dest port that other VOIP providers mention.


    Does this sound like a good idea guys? Excuse the naiveness, I'm just an artist :)
  13. lanmtl

    lanmtl Addicted to LI Member

    Toastman, I followed your QoS tutorial a while back. I am very happy with the result especially for VOIP with heavy usenet leeching but what bothers me is that upload speed is limited to about 75% of the line's capacity and download to about 80% even when there is no activity on the line.
    Are you saying there is a way to avoid this?
  14. Toastman

    Toastman Super Moderator Staff Member Member

    Ha! There is and there isn't - it does rather depend on what you and your users are doing.

    The aim is to try to give VOIP the highest priority and allow it to use the resources it needs. Tests by several respected bodies have recommended that the best way to achieve this is to limit incoming data to only 66% of maximum bandwidth so that there is always sufficient "spare" to be used for VOIP in any evetuality. Now, a few tests show that if you have very high incoming bandwidth available, 16Mbps and up (which probably was only a dream when those tests were originally done) then things may be different.

    What may be possible is to classify other applications to take more bandwidth if necesary - but to try to make it back off quickly if VOIP comes online and needs the bandwidth. This can be done by allocating ALL resources to VOIP such as 100 - 100 rate and limit, and NO incoming limit. Set overall incoming limit as high as you dare and test for yourself what impact it has on your VOIP when other apps are online. I've sometimes found outgoing P2P of 80% is OK, and even 85% - after that things got a little choppy.

    NB - One extra problem is actually that there is no effective OVERALL limit on incoming bandwidth. "Porter" has correctly pointed out that the figure we enter is only used as a base to calculate the limits for the other classes. So - it is possible for our "overall limit" figure to be exceeded by a combination of other classes.
  15. lanmtl

    lanmtl Addicted to LI Member

    Thanks for the additional info.
    I think I will stick to the current setup because I'm guessing that with this classification there isn't much room left for a decent WWW browsing experience, right?
    I always have trouble wrapping my mind around the fact that QoS works more like dividing the pipe in smaller ones (each for one class) with set speeds for each class regardless to the apps using it being online or offline rather than modulating each class' speed on demand. Correct me if I'm wrong though.
  16. Porter

    Porter LI Guru Member

    Unfortunately inbound and outbound traffic still gets treated differently. In outbound direction there occurs "borrowing" which means that the bandwidth not used by other applications is available to other traffic on the line. Keep in mind though that in outbound direction there is a guaranteed connection speed (rate) for a class (the left column under QoS/Basic-Settings) and and limit (ceil), the right column. One very important check is missing in Tomato's GUI as I just checked: the combined guaranteed outbound rates should never be higher than the whole outbound connection speed. This isn't being checked so you need to check yourself.

    The inbound traffic is rather imperfect when it comes to shaping because, as you said, it only devides your connection into several pieces that can't borrow bandwidth from another. The problem is described in detail there:

    Which config are you talking about? The one with the screenshots in "Using QoS"? If it's really important for you that at no point using your connection there is congestion occuring you should only have a few classes or you could try to not limit all your inbound classes (probably the ones that very rarely demand hihg speeds or don't use high rates anyway, but that really depends on your setup).
  17. lanmtl

    lanmtl Addicted to LI Member

    Thanks for the info, Porter.
    I am happy with my QoS setup, I was merely trying to see if I could tweak it.
    Your second question seems to be more directed towards OP so I will let him reply on that matter.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice