Why LibreQoS

We don't optimize applications. We control congestion.

Application optimizers speed up selected protocols with TCP proxies and payload inspection — and mask the queue buildup underneath. LibreQoS takes the opposite approach: explicit per-flow queue control at every subscriber circuit and every shared node above it, so the network behaves predictably for all traffic, and you can verify the result yourself.

The Architecture

Architecture questions to ask any QoE vendor

The answers below come straight from the LibreQoS documentation and source, not from marketing shorthand. Hold any vendor to the same list.

How are flows isolated?
Every shaped circuit gets its own queue envelope: HTB classes per Site, AP, OLT, and circuit, with CAKE (or fq_codel) as the leaf qdisc providing per-flow queues inside each circuit. Documentation
Does control depend on TCP?
No. Packets are classified by IP 5-tuple hash, so TCP, QUIC, and UDP all receive the same queue discipline. There is no TCP proxy in the path. Documentation
Is application DPI required?
No. Flow identity is resolved through a flow cache and longest-prefix match on addressing data — payload inspection is not part of the design. Documentation
Can it enforce subscriber plans?
Yes. Circuits carry per-circuit min/max rates, synced from billing systems such as Splynx, UISP, Sonar, Powercode, VISP, WISPGate, and Netzur — or from RADIUS accounting for dynamic circuits. Documentation
What about shared capacity?
The network hierarchy is modeled explicitly. Shared capacity at Sites, APs, OLTs, and backhaul links gets its own HTB class, so congestion is contained at the constrained branch instead of degrading everyone upstream. Documentation
How is congestion handled?
Explicit active queue management: CoDel inside fq_codel, and COBALT (CoDel + BLUE) inside CAKE, with fair scheduling between flows. Documentation
How is it deployed?
Inline as a Layer-2 Linux bridge between the edge router and the rest of the network, with a documented bypass path for production. Single-interface mode exists but is advanced and uncommon. Deployment guide
What hardware does it need?
Commodity x86 with an XDP-capable NIC (Intel X520/X710-class or Mellanox ConnectX). The eBPF/XDP fast path handles high throughput on ordinary server hardware — no proprietary appliance. Sizing and requirements
Is the source available?
The packet-processing core is GPL2 open source, so the algorithms shaping your traffic can be inspected. Insight and the API package are commercial add-ons. GitHub
What about central visibility?
Insight adds multi-shaper analytics: ASN-level analysis, RTT and retransmit history from 15 minutes to 28 days, and RTT, retransmit, and capacity heatmaps for every Site, AP, and OLT. Explore Insight
What evidence do operators get?
Per-circuit RTT, retransmits, flow detail, and QoO — an estimate of internet quality based on latency and loss, defined in the IETF IPPM QoO draft. Documentation
Can the result be verified independently?
Yes. The public Internet Quality Test measures idle and loaded latency, loss, throughput, and a QoO grade — anyone can run it against your network before and after deployment. Run the test

The Argument

Why this beats making selected applications faster

A TCP proxy can make a specific flow faster. It can also hide the cause of the problem: the queue that builds up at a constrained link during peak hours. When the optimizer does not recognize a protocol — or the traffic is encrypted in a way its classifier misses — the benefit disappears, and the underlying queue behavior is still there.

LibreQoS fixes the queue instead. Active queue management keeps latency low under load at the actual choke point. Fair queueing stops one heavy circuit from starving its neighbors. The hierarchy keeps local congestion local, so one constrained AP does not degrade every subscriber upstream of it. And this is not a novel bet: CoDel was published by Nichols and Jacobson in 2012, fq_codel and CAKE ship in the mainline Linux kernel, and the IETF community has spent a decade documenting bufferbloat as a queueing problem.

That design choice has a practical consequence: the result is observable. The source that shapes your traffic can be read. The before-and-after can be measured by anyone with a browser, and by you, continuously, in Insight.

Evaluating specific vendors? Compare LibreQoS and Bequant or compare LibreQoS and Preseem, each cited to the vendors' own published materials.

In Practice

What the architecture looks like in operation

Four design decisions operators notice in day-2 operations, not just in benchmarks.

Verify It Yourself

Don't take the architecture on faith

Run the Internet Quality Test on a busy-hour circuit, deploy LibreQoS on spare hardware or a pilot site, and run it again. The test measures idle and loaded latency, loss, throughput, and a QoO grade — the same evidence your subscribers would feel.

Deploy

Evaluate the architecture on your own network

Run the 1-line install on a pilot site, point your topology at it, and measure busy-hour latency before and after.