Additional Information:
Since QoS is such a big topic, additional information is presented here for those who want to dive a little deeper. While the example configuration is simple to understand and explain, we should go further in the real world. Also read the Bufferbloat article.
Protection with Limit-at:
In the event that traffic volume, for one particular queue, reaches at least 51% of the Max-limit value, that traffic will be subject to packet prioritization. This means packets might get dropped. This is normal and the whole point of what we are doing. But, what if that queue is your high priority queue? There is a way to carve out some protection for these special packets.
To illustrate how this is done, we’ll demonstrate with VoIP packets flowing in our VOIP queue. Each VoIP call is about 86Kb, both directions. Let’s say we have to protect 700 active calls to support a business contract. At 86Kb, that works out to be about 60M, which is indeed over 51% of our 90M Max-limit. Thus we set a Limit-at of 60M, on the VOIP queue only (both up & down). This will prevent those packets from ever being dropped. If you only ever expect 10 VoIP calls then Limit-at would be unnecessary.
Protection for low priority queues with Limit-at:
Why offer any protection for a low priority queue? If you have enough bandwidth to go around, it is a very good idea to carve out a minimum amount of bandwidth for busy queues. Otherwise, all higher priority queues will take nearly everything under ultra-high contention events. Thus, you could ensure at least 10M or more if you can afford it. QUIC and HTTP_BIG are queues that could use some level of protection.
Limit-at Qualifiers:
- You can’t protect more bandwidth than you actually have.
- Protection for one queue (only when under pressure) naturally forces the other queues to battle over what’s left.
- Attempting to protect more than 90% is risky. Better to increase bandwidth instead.
- Not everything on your network should be high priority. If so, then in reality, you only have one queue.
Implement like so:
# Set protection on VOIP queue, both directions. Also some for HTTP_BIG.
/queue tree
add limit-at=60M max-limit=90M name="1. VOIP" packet-mark=VOIP parent=DOWN priority=1 queue=default
add limit-at=60M max-limit=90M name="1. VOIP_" packet-mark=VOIP parent=UP priority=1 queue=default
add limit-at=10M max-limit=90M name="7. HTTP_BIG" packet-mark=HTTP_BIG parent=DOWN priority=7 queue=default
add limit-at=10M max-limit=90M name="7. HTTP_BIG_" packet-mark=HTTP_BIG parent=UP priority=7 queue=default
Optimizing the HTTP, HTTP_BIG, and QUIC queues:
Any queue that frequently hits the Max-limit value and has packets using global synchronization, Cubic, NewReno, or similar congestion methods, will benefit from a better queuing mechanism. Therefore, it is recommended to use RED (Random Early Detection) on these queue types. Note that WRED is an often mentioned improved version that looks at priority data in the packet. However, since we are placing packets in their own special queue anyway, we have already classified what is important.
Implement like so:
/queue type
# default queue behavior
set default kind=sfq
# queue behavior for streaming type traffic
add kind=red red-avg-packet=1514 name=redCustom
# example of how to use red, optionally set for all bulky traffic types
add name="7. HTTP_BIG" packet-mark=HTTP_BIG parent=DOWN priority=6 queue=redCustom
add name="7. HTTP_BIG_" packet-mark=HTTP_BIG parent=UP priority=6 queue=redCustom