Why Your QoS Priorities Don’t Match (DSCP, WMM and Switch Queues Explained)

You set up QoS.

You mark traffic.

You expect voice to be prioritized, downloads to be deprioritized, and everything to “just work”.

But in reality?

Nothing lines up.

Your switch behaves one way. Your Wi-Fi behaves another. And your carefully marked packets seem to lose their priority somewhere in between.

This is not a bug.

It’s a mismatch of three different QoS systems.

The Three Worlds of QoS

Modern networks combine three separate QoS mechanisms:

• DSCP (Layer 3 – IP header)
• 802.1p / PCP (Layer 2 – VLAN priority)
• WMM (Wi-Fi QoS)

Each one speaks a different “language”.

And Linux has to translate between them.

DSCP: The Global Intent

DSCP lives in the IP header.

It is supposed to represent the intent of the traffic:

• voice
• video
• best effort
• background

It is end-to-end and survives routing.

But it does not directly control hardware queues.

Switch QoS: The Hardware Reality

Your switch does not understand “intent”.

It has:

• 4 hardware queues
• a scheduler (WRR or strict priority)
• a simple classifier

Typically:

• DSCP ranges are mapped to queues
• or PCP (802.1p) is used

This mapping is often fixed or very limited.

So already:

DSCP ≠ queue

Wi-Fi QoS: A Different Universe

Wi-Fi does not use switch queues.

It uses WMM (Wi-Fi Multimedia):

• AC_VO (voice)
• AC_VI (video)
• AC_BE (best effort)
• AC_BK (background)

Packets are mapped like this:

DSCP → UP (User Priority) → WMM Access Category

But this mapping is:

• not fully configurable
• not identical to switch mappings

So again:

DSCP ≠ WMM (exactly)

The Core Problem: Translation, Not Control

At every boundary, something translates QoS:

• IP → switch (DSCP → CoS)
• CPU → switch (DSCP → PCP)
• IP → Wi-Fi (DSCP → WMM)

These translations are:

• lossy
• hardware-dependent
• not always consistent

This is why your priorities “don’t match”.

Why This Gets Worse With Offload

Modern routers rely heavily on:

• hardware switching
• flow offload
• Wi-Fi acceleration (WED)

These bypass parts of the Linux networking stack.

Which means:

You lose opportunities to “fix” QoS in software.

If the headers are wrong, the hardware will happily enforce the wrong priority — very efficiently.

The Only Model That Actually Works

Instead of trying to control everything, you need alignment.

A simple and effective model is:

• use DSCP as the single source of truth
• map DSCP into 4 classes (VO / VI / BE / BK)
• ensure all domains interpret those classes consistently

This means:

• switch uses DSCP ranges
• CPU port maps DSCP → PCP
• Wi-Fi maps DSCP → WMM

Not perfect.

But consistent.

RouterWRT’s Approach: Consistency Over Complexity

Instead of exposing dozens of QoS knobs, RouterWRT focuses on:

• aligning DSCP, PCP and WMM
• using hardware queues efficiently
• avoiding fragile software-only solutions

The goal is not to build the most complex QoS system.

It is to build one that actually works across:

• Ethernet
• Wi-Fi
• hardware offload paths

Conclusion

Your QoS is not broken.

It is just speaking three different languages at the same time.

DSCP defines intent.

Switch hardware enforces queues.

Wi-Fi uses airtime-based prioritization.

And Linux sits in the middle, trying to translate between them.

Once you stop fighting that — and start aligning it — QoS suddenly becomes simple again.