Question about QoS

Hi there,

I'm not a newbie to OpenWrt but somehow, I'm a bit lost finding the right entry into QoS

I want to do a QoS / traffic shaping on inbound internet traffic (not local originated traffic)

I'm using OpenWrt as a firewall on a central router (BananaPI).
Internet is connected by 2 VLANs: eth0.8 and eth0.10 (DSL and LTE backup), the clients are distributed over some more VLANs for separating servers, normal clients, remote working clients (for home office), guests and streaming.

How to I sort the internet traffic to the VLANs/subnets/devices into e.g. htb classes?
For example: Servers, normal clients and remote working clients are the highest prio with a guaranteed minimum rate. Streaming is normal with no guarantees and guests are the lowest prio also with no guarantee.

I think this could be achieved with a htb scheduler but I didn't found answers how & where to mark the packets and how to deal with the outbound interfaces. Or would I do this before the internet traffic is routed to the subnets (after demasquerading)?

Thanks for any kind of help!

Hi AndiDepressivum, welcome to the community!

From the sounds of it you don't control the choke point on the other side of the inbound traffic. Traffic shaping is only useful... scratch that... traffic shaping is only possible where you control the choke point. The point where on one side you have a faster connection than on the other.

The only mechanisms for traffic shaping are delaying or dropping packets. Doing either after the packet has arrived over the slow link is unhelpful. You can't shape inbound DSL traffic unless you have something on the other side of the DSL link making decisions on which packets to let through.

You can shape your outbound traffic in the hopes that inbound will approximately mirror that, but unfortunately most inbound traffic is asymmetric to the size of the outbound request.

Sure, you're right but normally the TCP flow control will handle the rest when I for example put a tbf on an interface to slow it down.

I did something similar about 20 years back on a linux router handling an 768kbps DSL downstream with sfq. It worked fairly well to distribute the downstream equally to the clients no matter how many downloads they've started.

At the moment, I've placed a htb to the wifi interface the Amazon Fire stick is connected to with a rate of 8mbps to prevent it to saturate the 50mbps DSL downstream when my wife starts a new movie. Since I've made this, my Teams business video calls are no longer distorted when someone starts a new movie.

But instead of doing this on a single interface I want to do it centrally in the firewall/router.

Well, that is why in sqm-scripts (and qos-scripts, and qosify, and ...) we create an artificial bottleneck for ingress traffic on the OpenWrt router, under many conditions (with responsive traffic) that allows us to meaningfully control the ingress traffic as well, good enough so that QoS hierarchies can be built on top if one desires.

I would recommend to start out with sqm-scripts/luci-app-sqm configured for per-IP-fairness with cake/piece_of_cake.qos as a stop-gap measure while you research how to built your preferred elaborate QoS hierarchy.

Per-IP-fairness will equitably divide your capacity between active machines/IP addresses, and within each IP-address equitably between flows. This is NOT the end state you want to reach from your description, but it should be a better place to "wait in" while building your desired QoS tree.
For a number of users 9but by no means all) per-IP-fairness is already good-enough and they stopped right there... (sqm-scripts also offers different priority modes for the cake qdisc, like diffserv3/diffserv4/diffserv8 that might allow you to add a sprinkle of classic priority QoS on top of per-IP-fairness).

That is a bit tricky, as you need to perform this sorting before HTB gets hold of these packets... that means e.g. raw tc filter commands or qosify's eBPF approach, or moving the ingress shaper onto an interface inside the NAT domain so iptables/nftables can be used...

This really depends on what you want to achieve.

Technically correct, but it turns out traffic shaping on the ingress side, while not as strict as on the egress side works pretty well, and it is doing so since more than a decade... Sure it will not stop a DOS attack and have problems with unresponsive traffic, but for most "normal" traffic mixes it works surprisingly well.

For typical TCP Reno, the reverse ACK traffic will be around 1/40 the volume of the forward data traffic, so if you want to "choke" the ingress data traffic you would need to shape the egress traffic down to < 1/40 of the data rate, technically doable, but not a great idea...

Start with sqm-scripts instantiated on your WAN interface, as a stop-gap measure until you have figured out what you want to do with HTB. You can also have a look at sqm-scripts' simple.qos script for a simple 3 tier HTB set-up with some mild filterings.

1 Like

Thank you, I'll do!

Two questions which I'm still not aware of:

  1. Does it matter if I use a single ethernet interface splitted in VLANs (e.g. WAN connection on eth0.8 and eth0.10, lan, guests, etc. on eth0.3, eth0.4, ...)?
  2. Is the script aware of the new nftables which came along with OpenWrt 22? Or doesn't it matter?

Yes, of course it does. In that case make sure to instantiate sqm only on the WAN-VLAN, e.g. eth0.8 if you instantiate a shaper on eth0 this will affect all VLANs as well IIRC.

Yes and no, piece_of_cake.qos and layer_cake.qos do not really use iptables IIRC, simple.qos however will, but should be happy with nftables compatibility iptables shim-binary