LibreQoS Quality of Outcome

Quality of Outcome (QoO)

A 0–100 score per application, not just a speed number. QoO asks how well a connection actually handles video calls, streaming, gaming, and the rest under load.

How a score is built

Weakest link

Each application is scored on three dimensions. Every dimension is compared against two thresholds: the point where the application is as good as it needs to be (100%), and the point where it becomes unacceptable (0%). The application score is the minimum of the three.

QoO = min( latency, loss, throughput )

Latency

Loaded round-trip time at the 95th percentile, scored on a straight line between the good and unacceptable thresholds. This is where bufferbloat shows up.

Loss

Mean packet loss during the loaded phase, scored the same way. Real-time apps feel loss long before throughput suffers.

Throughput

A pass/fail gate against the minimum rate the application needs in each direction. Meet it and throughput does not cap the score; miss it and the app scores zero.

Taken as a minimum, the weakest dimension decides the score. A fast connection with high latency under load does not score well for a video call.

Per-application thresholds

LibreQoS defaults

These are the thresholds LibreQoS uses. Throughput is a pass/fail minimum, downstream / upstream. Latency is p95.

Application Latency (good → bad) Loss (good → bad) Minimum throughput (down / up)
Browsing 60 → 600 ms 0.5% → 5% 5 / 1 Mbps
Streaming 90 → 1200 ms 1% → 4% 7 / 1 Mbps
Video calls 70 → 200 ms 0.8% → 3% 3.5 / 3.5 Mbps
Phone (audio) 90 → 250 ms 1% → 4% 0.3 / 0.3 Mbps
Backup 180 → 2000 ms 2% → 10% 1 / 20 Mbps
Gaming 55 → 140 ms 0.5% → 2% 1 / 1 Mbps

The application classes and values above are LibreQoS implementation defaults, not thresholds prescribed by the IETF. They can be tuned per network or use case. Streaming’s minimum is the 1080p rate.

How we score throughput

Pass / fail

Throughput is a gate. If the connection meets the minimum rate the application needs, in both directions, the throughput term is full marks; if it does not, the term is zero and the application score is zero. This matches the QoO draft, which scores throughput as pass or fail at a minimum required rate.

The minimum rate is different for each application and is chosen by LibreQoS, as the draft leaves application requirements to the implementer. Latency and loss remain graded, so they carry the quality signal while throughput decides whether the application can run acceptably at all.

How we measure and combine

Method
  • The path is loaded in each direction, and latency and loss are measured while it is loaded.
  • Two-way applications are scored on the worse of the download and upload phases, so a problem in one direction cannot hide.
  • Streaming is scored on the download phase, backup on upload, browsing on the loaded phases.
  • The bidirectional phase is a diagnostic stress test and is never used for a QoO score.
  • Idle latency is a reference point for the overall A–F grade, not a QoO input.
Excellent90–100
Good80–89
OK60–79
Poor0–59

Standards note

draft-ietf-ippm-qoo

QoO is defined by the IETF IP Performance Measurement working group in draft-ietf-ippm-qoo. LibreQoS implements the framework’s weakest-link aggregation, its latency and loss scoring, and its pass/fail throughput gate. The per-application minimum rates are LibreQoS choices, as the draft leaves them to the implementer.