Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 10 replies
  • Subscribers 2 subscribers
  • Views 5600 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

How is QoS supposed to work, again ?

StephaneGROBETY
Hello,

Historically, QoS "bandwidth reservation" in Astaro used to really reserve the bandwidth indicated: if you have a 20 Mbps link, made a 5 Mbps bandwidth reservation and started a download, it would peek at 15 Mbps.

Right now, I'm trying to diagnose an issue with VoIP: we have a 4096 Kbps reservation setup with a traffic selector that is quite wide: any UDP packet to or from our SIP provider network should match it.

Yet, when we start a download over our 20 Mbps link, the download speed goes all the way to 20 Mbps.

After checking that: the WAN interface is setup with the correct bandwidth value, the traffic selector are definitely wide enough to catch the SIP traffic, the reservation is made properly (correct traffic selector, correct interface, correct bandwidth pool), I can only come to two conclusions:
- The system doesn't work as it used to (or I always was mistaken) and it's now able to dynamically detect when reserved bandwidth is actually necessary (in which case I suppose  BW reservation is not only some kind of "hint" used to figure out what traffic to prioritize up to which point) 
- Bandwidth reservation doesn't work at all (furthermore: we have had some other reservation for a looong time - since ASLv6 at the very least and I'm not seeing it either)

Which one is correct ? Any other explanation ?

(And no, it doesn't seem that VoIP is affected by the non-matching traffic: as far as I can tell, the firewall is actually working fine, not just the way I thought it would).


This thread was automatically locked due to age.
  • 0
    I don't use my QoS for VoIP right now.....
    But, I use it for Video streaming / skype (So.... kinda voice)

    From what i've read, the UTM will not carve it out and not allow anyone else to use it.  Instead, it allocates up to that amount as needed, and gives it priority.  If VoIP isn't using the full 4096, it will let other applications use that bandwidth.
    If you had VoIP using the full 4096, you should see a max download of ~15 Mbps.

    4096 for voice is a lot!  [:)]  What codec are you using, and how many lines?
  • 0
    Bandwidth Pools always have worked like Rx7TyreBurna says.  They apply only to uploads.

    In order to regulate inbound traffic in V9, you use Download Throttling rules, and these do result in bandwidth being limited like fulgan says.  To reserve inbound bandwidth for VoIP, create, in order:
    [LIST=1]External : Limit to 20Mbps : Internet -> VoIP -> Any
    • External : Limit to 16Mbps : Internet -> Any -> Any
    [/LIST]
    Cheers - Bob
  • 0 in reply to BAlfson
    Interesting.  Thanks Bob for clarifying!
  • 0 in reply to NathanCole
    Bob,
    Is it better to apply Download Throttling, or to put QoS on an internal device, and throttle it's upload?

    So, I have an internal network card, my WAN is 14 Mbps down / 768 kbps up.

    I set the LAN interface speeds to 768 down / 14 Mbps up, because on the LAN interface, the 'up' is what is leaving the NIC and heading to the LAN, right?

    Then, I give that 3.5 Mbps for hulu.

    Is there an advantage to the Download throttling over that other way?
  • 0
    Hi,
    The standard QoS system doesn't work on inbound traffic; you can put QoS on the LAN interfaces to compensate, or use the new Download Throttling system (which should be more straightforward).

    Barry
  • 0
    Eh? I think you mean it doesn't work on *inbound* traffic.
  • 0 in reply to trollvottel
    QoS is really not that difficult guys. Do some testing instead of worrying about historical precedence. 

    1. Bandwidth pool has to be applied to the right interface for it to be effective.

    2. Generally people apply qos to their outbound / outgoing traffic but you can apply it to incoming traffic and it works fine also. The only downside is that incoming throttling is achieved by dropping packets which may not be a optimum solution in voip situations.

    3. Newer astaros use HFSC which means that it prioritizes traffic. This means that if voip is not using any traffic, the traffic will get used by other queues (more efficient) instead of not getting utilized at all. Of course you can put hard limits on your pools if you like.
  • 0
    Is it better to apply Download Throttling, or to put QoS on an internal device, and throttle it's upload?

    The only downside is that incoming throttling is achieved by dropping packets

    As Billybob implies, the same thing happens - the new Download Throttling capability is just easier to understand.

    Cheers - Bob
  • 0 in reply to trollvottel
    Eh? I think you mean it doesn't work on *inbound* traffic.


    oops... fixed.

    thanks,
    Barry
  • 0 in reply to BAlfson
    As Billybob implies, the same thing happens - the new Download Throttling capability is just easier to understand.
    Packet drop is not a bad thing and is actually how tcp/ip is supposed to work. QoS is not a substitute for lack of bandwidth. In fact, QoS drops packets in both inbound and outbound direction when your bandwidth is exhausted. The only difference is that by dropping lower priority packets, you can utilize that bandwidth for a better overall experience.

    During upload throttling, QoS tries to queue the packets in order of highest priority. However if there are still more packets in the queue than what your bandwidth can handle, you have better control over what traffic to drop. So for example you can drop a few ftp packets or smtp packets that nobody would notice while your voip traffic is working flawlessly.

    However when the incoming packets are dropped, you don't have any control over what the ISP router is sending and you are dropping packets that have already reached your router. Although you are still dropping ftp packets at your end as before, the ISP router will not change its behavior and will still queue ftp packets with voip traffic without priority and you would not see the apparent benefit of QoS. Download throttling works great if you want to limit bandwidth to certain segments of your network. It is not good for guaranteeing bandwidth to a certain application.

    Hope it makes sense[;)]