Turn QoS policies into proven SLAs with class-based performance tests.
Most organisations define “priority” traffic in policy documents, but the leap from a policy to a provable service level is where many stumble. To create SLAs you can stand behind, begin by translating business intent into discrete, measurable QoS classes tied to applications and outcomes.
Voice and critical control traffic may require tightly bounded delay and jitter; batch data and backups tolerate latency but not excessive loss; interactive video sits somewhere in between. Use DiffServ semantics to make these intents portable across vendors.
The IETF’s guidance on service classes remains a practical starting point for mapping traffic types to per-hop behaviours - see RFC 4594. With classes defined, write acceptance criteria that echo how users feel performance: p50/p95/p99 latency rather than just averages, jitter windows for real-time, and loss rates under load.
Define Committed Information Rate (CIR) and Excess Information Rate (EIR) for classes where bursting matters, along with drop eligibility and shaping rules. Equally important is specifying what the SLA does not cover: impairment boundaries, packet sizes, routing domains, and time-of-day ranges. Avoid vague language - be explicit about thresholds and measurement methods.
Finally, align network marking and policing with application behavior. Ensure DSCP values are set at the source or via policy enforcement, and that middleboxes preserve markings. If an SD-WAN overlays multiple transports, specify how each class maps onto underlay queues to prevent accidental downgrades. The result is a contract that engineers can test against and stakeholders can understand.
Single-flow tests rarely reflect production. To validate QoS properly, you must exercise multiple classes concurrently, at realistic utilisation, while observing per-class outcomes. A solid approach includes parallel streams for voice, video, critical apps, and best effort, each with class weights reflecting your policy.
Drive offered load to 70–90% of link capacity, then introduce controlled bursts and impairments to watch priority behaviour: do high classes maintain bounded latency and low loss while lower classes shed load gracefully? Measure latency percentiles per class, not just aggregate figures, and record jitter for real-time streams. Include microburst scenarios to observe queue headroom and AQM behaviour; if your instrumentation supports it, track ECN markings and drop counters per queue.
For passive and hybrid performance monitoring on live traffic, the IETF’s Alternate Marking method provides a useful pattern; see RFC 8321. To make the test conclusive, verify that DSCP markings survive across segments and that policers and shapers enforce CIR/EIR as designed.
Introduce fairness checks: do elephant flows in best effort starve mice flows in a higher class? Validate application proxies - for example, SIP call setup and MOS for voice simulations, or transaction per second and p95 latency for critical App's - so the results map to user experience.
Capture evidence automatically: per-class throughput, p95/p99 latency, jitter, and loss across the run, with event markers when bursts or failure injections occur. This produces a traceable artefact that stands up during audits and vendor discussions.
Testing is only valuable if it leads to predictable operations. Turn your one-off QoS validation into an assurance practice with cadence, evidence, and governance.
Cadence means scheduling periodic multi-class tests - before go-live, after policy changes, and quarterly to catch drift.
Evidence means storing artefacts in a system of record: test definitions, configurations, timeseries, and a one-page attestation per circuit summarising pass/fail against thresholds and the scope and caveats of the test.
Governance ties it together: name owners for each class, require change control for DSCP maps and queue weights, and track exceptions. When possible, complement synthetic tests with lightweight always-on telemetry that watches per-class latency and loss in production; correlation makes incident response faster and keeps SLAs honest.
For design updates, refer to standards and vendor design guides so changes remain defensible; the class mapping guidance in RFC 4594 helps anchor intent across platforms. Over time, this discipline eliminates the gap between what your QoS policy promises and what your network actually delivers. It also improves relationships with service providers: empirical, per-class evidence shortens the debate when a carrier queue misbehaves.
For organisations in Australia and New Zealand, where transport options and last-mile constraints vary, this practice provides a pragmatic, repeatable way to guarantee experience to distributed teams and critical sites without overspending on bandwidth.
Matrium Technologies is a provider of Network Testing solutions and services that helps our customers ensure SLA's and QoS are validated and optimised for performance.