QoS in a small network

Question

I have a small engineering network with a Linux router, LAN nodes on the one side of the router, and a WAN link attached to the router. The WAN link is a 16mbit/s wireless channel, while the LAN nodes have 100mbit/s fast ethernet connections. The LAN nodes generate traffic, including commands and data. Commands are small packets (hundreds bytes) with 10-15 pps rate with a real-time need. Data is the other type with a few Mbps rate.

What I'm trying to do is to share the WAN link in a best way: high priority packets (commands) should occupy the WAN first, then everything else for other data.

So after I have read a lot of docs across the Internet I realized to organize kind of traffic management on the Linux router using tc and HFSC Scheduling in particular.

Now I think about next simple config:

# eth0 is the WAN link
tc qdisc add dev eth0 root handle 1:0 hfsc default 20

# Define overall bandwidth
tc class add dev eth0 parent 1:0 classid 1:1  hfsc sc rate 16mbit ul rate 16mbit

# This class is for commands
tc class add dev eth0 parent 1:1 classid 1:10 hfsc rt m2 16mbit

# And this one is for everything else
tc class add dev eth0 parent 1:1 classid 1:20 hfsc ls m2 16mbit ul m2 16mbit

And a filtering part:

# This is for commands
tc filter add dev eth0 parent 1: protocol ip prio 1 u32 match ip dst 224.0.0.0/4 flowid 1:20
# This is for everything else
tc filter add dev eth0 parent 1: protocol ip prio 2 u32 match ip dst 0.0.0.0/0 flowid 1:10

And some tuning with SFQ as queue inside each class:

# tc qdisc add dev eth0 parent 1:10 handle 10: sfq perturb 10
# tc qdisc add dev eth0 parent 1:20 handle 20: sfq perturb 10

So using this config I expect that packets with commands should be processed as fast as possible with minimum delay. Is this config fine and complete or totally wrong?

Unfortunately I can't test this config on a production network before I'm sure that it will work.

Answer 1

I don't know the specifics of QoS configuration for your router or switch(es), but this is how QoS should work for the requirements you have described. You may be able to use this to come up with a configuration for your needs.

QoS is really several separate things working together, and your need is fairly common.

First, you should use shaping on the WAN port if the port's native line rate is higher than your CIR. For instance, if your WAN port is a 1 Gb ethernet port connecting to a device providing a 16 Mb path, shaping is in order. On the other hand, if the native line rate of the port really is 16 Mb, you don't need to shape. Shaping can be a little more complex than it first seems. Your CIR is 16 Mb. You should account for some protocol overhead, and if there are many small packets, you will need to account for more protocol overhead since smaller packets have a smaller payload-to-overhead ratio than larger packets. You should set a shape rate at some percentage of the CIR. You can narrow this down by traffic observation, and fine tune it later. This percentage may be as low as 80% or so, or it may approach 97% or 98%. It all depends on the protocol overhead of your traffic mix.

Next, you should identify and mark the various classes of traffic as close to the source of the traffic as possible. For instance, as traffic comes into the router, or, better yet, on the switch if it supports QoS marking. Mark traffic like the commands with a higher priority and ordinary traffic as best effort or various marking(s) that fit your needs. You can have multiple classes of traffic, each marked differently.

Finally, you get to queuing. You should create a priority queue for the priority traffic. This queue can have a guaranteed minimum bandwidth, or percentage of the bandwidth, and it can be served before any other queues. You assign the the traffic marked for priority to this queue. Create queue(s) for the other class(es) of traffic that you have identified and marked and assign to the respective queue(s). Other, multiple queues can have various bandwidths, or bandwidth percentages, assigned, but they may not necessarily be priority queues with guarantees.