Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 10 replies
  • Subscribers 2 subscribers
  • Views 5603 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.
Parents
  • 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.
Reply
  • 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.
Children
No Data