Shaping traffic for VOIP using HFSC



  • Hello All.

    I've been trying to figure out how to setup shaping for a cable connection that is is the main connection for a small office. It handles all connectivity including voip. Previous to the new cable connection, we had DSL and a m0n0wall firewall which did shaping using dummynet. This worked well, but severely limited upstream bandwidth.

    When we got the new connection, we upgraded to pfsense 2.0 RC1 and it has been working well. BUT I can't seem to figure out how to limit the upstream bandwidth. When the upstream gets too saturated, it causes problems with the VOIP quality. Downstream seems to have a lesser effect on the quality. To handle this using dummynet, I had a pipe that only allowed a small portion of the connection and didn't affect VOIP quality. Unfortunately that meant that regular users only got a small portion of the connection and couldn't "borrow" from the other pipe. Good for VOIP, but bad for users. I'd love to have users be able to use the full capacity of the connection, but make sure to serve VOIP first and reduce the connection speed if it's starting to approach the limit of the connection.

    I thought that perhaps smarter shaping could solve this, but it hasn't seemed to be that way yet.

    Eg. Today a large upload was started (not sure what type) and it uploaded at ~1.2Mb/s and causes the "quality" of the connection to  become much poorer(you can see quality in the RRD quality tab). This is mostly an issue when using VOIP. I've tried setting the upstream bandwidth to a lower setting (below the 1.5Mbps rating of the line, but it still doesn't seem to fix the issue.

    WAN
      Scheduler - HFSC
      Bandwitdh - 1.2 Mbit/s

    Then I have (as children)
      qACK (priority 7, bandwidth 19%, link share (m2) 19%)
      qDefault (priority 3, bandwidth 10%)
      qP2P (priority 1, bandwidth 3.5%, upperlimit (m2), 3.5% link share (m2) 3.5%)
      qVOIP (priority 6, bandwidth 50%, Real time (m2) 50%)
      qOthersHigh (priority 4, bandwidth 9%, link share (m2) 7%)
      qOthersLow (priority 2, bandwidth 3.5%, link share (m2) 3.5%

    Anyone else have a good VOIP setup that doesn't limit the other connections unless VOIP is actively using the connection? Is there a better way?



  • What I did: forget HSFC, just use PRIQ.  Unless there is VOIP traffic pending to go out, all available BW is available for default traffic, just need to make sure you have realistic BW limit for your connection.



  • @adroitboy:

    Eg. Today a large upload was started (not sure what type) and it uploaded at ~1.2Mb/s and causes the "quality" of the connection to  become much poorer(you can see quality in the RRD quality tab). This is mostly an issue when using VOIP. I've tried setting the upstream bandwidth to a lower setting (below the 1.5Mbps rating of the line, but it still doesn't seem to fix the issue.

    It looks like voip traffic does not go to the correct queue. Pls double check qVoIP for uploaded and also downloaded packets.



  • I too am wondering if my traffic is being ID'd correctly. I was looking at the queues and it's almost impossible to tell the difference between the queues because of the color scheme. Is there some way to choose a different scheme?



  • I do know that at least some of the traffic is being ID'd correctly, but it appears that not all of it is. When I look at the live queue view, it shows around 90K in the Default Queue and ~90K in the qVOIP queue. Since endpoint is not local to the server, that would make sense that only one leg is getting tagged as VOIP. Now to figure out why.

    Still wondering on the color scheme. It's almost impossible to determine which color is which.



  • The Web UI does not give you much information. Use pftop from the console instead (option 9).



  • Hi, can you give me a hint on pfTop, how to tell what queue the traffic is going in?  I have the same problem, that I can't get Voip traffic to go in the right outgoing queue, I'm assuming we are talking about UDP traffic, and what i am seeing is that it just doesn't behave the same way as TCP, as far as going in the right queues.



  • In pftop, Queue View (#8) shows actual traffic amount in individual queues and Rule View (#6) shows traffic amount by individual rules so that they should tell you whether the shaping takes its effect and also how accurate it is.


Locked