Quality of Service

Starting with Core Update 163, the Quality of Service (QoS) in IPFire is based on CAKE. CAKE (Common Applications Kept Enhanced) replaces fq_Codel as the advanced queue management algorithm powering IPFire’s QoS. As described in the CU163 release notes, “CAKE comes with a couple of benefits over its predecessor of which requiring less CPU resources, more accurate bandwidth shaping due to working with bytes instead of packets the most important ones.” Up to CU187, CAKE is used throughout IPFire to prevent interface congestion even if QoS is not enabled.

Starting with CU188, IPFire uses fq_Codel by default for interface congestion if QoS is not enabled. However, if QoS is turned on, then CAKE is used for QoS and IPFire’s internal use.

Introduction

IPFire supports Quality of Service (QoS) policies which allow bandwidth to be reserved for specific types of traffic. This means that when a network connection is congested, high priority traffic will be processed before low priority traffic. Also, due to the ability to sync bandwidth with the user’s ISP, network buffers are equalized, reducing latency and jitter dramatically. This reduces or eliminates what is commonly referred to as Bufferbloat.

Both upload and download limits can be configured separately. Different types of traffic (classes) can be configured to have different priorities and a set amount of guaranteed bandwidth. When bandwidth is needed for a Class, the QoS algorithm intelligently decides if it needs to borrow potential bandwidth from a lower priority Class in order to maintain the minimum guaranteed bandwidth that is defined. Even if most of the bandwidth is used up, an amount is still reserved and given if needed, based on the user-configurable settings "Priority", "Guaranteed Bandwidth" and "Maximum Bandwidth" under each Class.

IMQ Device

The IMQ (Intermediate Queueing Device) is a virtual network interface in IPFire designed to handle incoming (download) traffic. When incoming packets reach the external "RED" interface (red0), they are enqueued to the imq0 device during the PREROUTING chain for QoS processing before entering the local network. This setup enables precise control over download traffic, facilitating prioritization or rate-limiting as needed.

Configuring QoS in IPFire

Using the IPFire web user interface, click "Quality of Service" in the "Services" menu.
Before starting, ensure QoS is stopped.
Click the Modify button to change the Downlink (download) and Uplink (upload) speeds to what your ISP provides in kilobits per second format.

Calculate Bandwidth for QoS

While your network is quiet (there is very little other traffic) find your upload and download speed using services such as Speedtest.net or Testmy.net. There are also sites that test for bufferbloat that could be used for both speed checks and QoS tuning. Two such sites are Cloudflare Speedtest and Waveform Bufferbloat.

If your speed is in Megabits, multiply that number by 1000 to get Kilobits.

Multiply that number by 97% (.97). This reduces your internet bandwidth by 3% to ensure network buffers are not exceeded. Example:

60 Megabits Download = 60 x 1000 x 0.97 = 58200
12 Megabits Upload = 12 x 1000 x 0.97 = 11640

You can adjust that percentage based on your observed latency.

This makes the connection between your router, the modem and the internet (ISP Limit) about the same. As both your router (IPFire) and your internet connection will be around the same speed, your modem will not need to buffer traffic. In some cases, more than 3% will further reduce latency. Tune per your specifications. Is less latency worth more to you than slightly less bandwidth? You decide.

Class

Classes define the priority, guaranteed bandwidth, maximum bandwidth and TOS for a set of communications you define.
Classes which begin with 1 (101, 102, etc) are outbound rules. These control traffic being uploaded on your internet connection, such as sending email or uploading a document.
Classes beginning with 2 are rules for your download bandwidth.
Special Classes include 101, 110 and 210. It is highly recommended not to change these three classes as it may cause problems with QoS in IPFire.
110 and 210 are defined as Default uplink and downlink respectively. All traffic which does not match any other class will be regulated by this class. These classes should have low priority (6 or 7) and conservative Guaranteed Bandwidth values to ensure they stay out of the way of higher priority traffic.
101 is defined as the ACK class, for acknowledgement packets.

Priority

Traffic that is defined by a class with priority 1 will be given priority over all other traffic. Priority 7 has the lowest priority.

Carefully consider which types of communications are most important. For example, your network may be used for VoIP and video calls. These types of communications need to have high priority as any delayed packets will be discarded leaving users with choppy audio and video.

Also, if you mostly use a VPN after hours, it might make more sense to prioritize VPN below web traffic. Otherwise, when someone does use VPN during work hours and it is prioritized above web traffic, it could negatively impact web traffic performance for many users. In contrast, if most users work from home, then it might make sense for VPN traffic to have a higher priority than web traffic.

Guaranteed and Maximum Bandwidth

Use Kilobits per second format. Guaranteed bandwidth will reserve a certain amount of your bandwidth to a Class regardless of its priority. A good rule of thumb is the sum of your guaranteed bandwidths for a particular class should be less than or equal to your maximum available bandwidth. This will ensure that all classes can get their guaranteed bandwidths simultaneously without exceeding the total available bandwidth from the ISP. For example, if your ISP provides 100Mbit downloads, you might reduce your maximum bandwidth to 97Mbit/sec (3% less than max), then make sure the sum of all of your class 2 guaranteed bandwidths is no more than 97000Kbit.

Maximum bandwidth is how much bandwidth you would like the Class to have when there is extra bandwidth available. In most cases, this will be at or close to your ISP’s maximum. However, in some circumstances, it may make sense to throttle this more. For example, if your VPN connection is limited by a low uplink speed on the remote end, you might match your local VPN download maximum with the remote end’s upload limitation.

Burst

This optional field defines the packet size for data that will be sent at the Class maximum bandwidth. When you leave this field blank, IPFire defaults to 1600 bits. Some experimenting with this value (see footnote¹) has determined that the default value seems to work best, but you may choose to manually change this. The value you enter should be in kilobytes. So if you wanted a bit value of 5120, you would enter 5 (5 KB = 5120 bits). In other words, divide the bit value by 1024 to get the value you will input.

Ceil Burst

This optional field defines the packet size for data that will be sent at maximum link speed (the downlink and uplink speeds you define at the top of the QoS page). The value also defaults to 1600 bits, which seems to be ideal for most cases (see footnote¹ for more discussion).

TOS

Type of Service (TOS) lets you define the bits of traffic sent from each class with an IP header value that receiving routers can use to further prioritize traffic. Select the appropriate value from the drop down box.

Option	description	TOS bit
disabled	no special treatment for the packet	(0)
minimum costs	prioritizes cost-efficient transmission in paid-for based on usage	(1)
maximum reliability	avoid congestion and packet loss	(2)
maximum throughput	large file transfers or bulk data sharing	(4)
minimum delay	real-time voice and video communication	(8)

Defining class traffic

After all classes have been defined, click the Green pencil icon to add a rule for each class
Use Port-Rules where possible as they require the least computing power for IPFire to process. These require a knowledge of the protocol and port used by a particular communication and are not ideal for traffic which can use random ports.
For Uplink (Upload) rules, specify the Destination Port
For Downlink (Download) rules, specify the Source Port
Level 7 Rules can be used to catch traffic which use random ports (or if you expect users will try to avoid your Quality of Service rules!)
Use these rules sparingly as they are less efficient and require higher CPU utilization for your IPFire router
TOS rule allow you to put all traffic which is already tagged by another router in to a class which you have defined. Depending on the complexity of your network this may have minimal benefit.
In its default state, IPFire's QoS configuration sets the IMQ_MODE to "PREROUTING." Due to this, local IP addresses cannot be used to define downstream rules, as the QoS operates on the RED interface, which is processed before NAT. If you find it necessary to use local IP addresses in your downstream rules, you can't change this via a settings file. Instead, you'll need to manually edit the Perl script located at /var/ipfire/qos/bin/makeqosscripts.pl. In this script, modify the iptables entry to place the mangle table in the "FORWARD" chain, as opposed to the default "PREROUTING" chain.

Tips

For each Class, make sure the sum of the guaranteed bandwidths is equal to or slightly less than your total bandwidth for that Class.
Use a bufferbloat testing site to check your configuration. Ideally, you want to maintain most or all of your ISP bandwidth while eliminating most or all latency.
Observe the uplink and downlink graphs for a period of days. Note the highest values under the "Maximal" column and use those to help determine your Guaranteed and Maximum bandwidths for each Class. For example, for Class 101 (ACKs) if the highest value ever recorded is 70 KB/sec (560 kbit/sec), then it might make sense to set the guaranteed bandwidth to 500 and the maximum to 600.
The slower your internet connection, the more effective QoS is at improving internet performance. This is because QoS is designed to improve responsiveness in low bandwidth, high density network environments. If your internet speeds are higher than 150 Mbps than QoS will be less noticeably effective.
Depending on the CPU in your IPFire device, QoS may throttle your bandwidth below your settings due to the computational requirements of QoS. This is more likely at internet speeds of 150 Mbps or more. Higher CPU MHz is more effective at maintaining fast line speeds with QoS than more cores.
If you name and order your uplink and downlink classes identically, their colors on the graph will match.
An example custom configuration is available in footnote².

Advanced Editing

If you are an advanced user and comfortable working in a Linux shell, the easiest way to make major changes to QoS configuration is to edit the files directly in IPFire.

Be very careful when editing files directly, there is no error checking for mistakes so you could easily make a change which causes QoS to fail!
Make a backup copy of the /var/ipfire/qos/ directory before making changes
All settings in the QoS WUI are defined in text files in the /var/ipfire/qos/ directory. Most files are semicolon ; separated variable files.
After making changes, it's easiest to restart QoS using the WUI. You should also check the IPFire logs (especially the Kernel log) for errors.
Classes can be customized. This includes adding classes, changing Port-Rules, Level 7 rules and TOS rules. It is best to make such customizations from the terminal, following the guidelines above regarding backing up the QoS directory prior to starting so that if things go wrong, you can restore the known-good configuration easily.