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 ?

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
  • 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
Reply
  • 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
Children
  • 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[;)]