DSCP policies for SQM (CAKE) with real-time conntrack visibility

Community Builds, Projects & Packages
1

Hi everyone,

I’d like to share a small experimental project built around SQM + CAKE,
focused on DSCP-based traffic policies and real-time visibility.

The project consists of two independent parts:

  1. A custom SQM script (CAKE-based)

    • Uses nftables to apply DSCP policies
    • Stores DSCP values into conntrack
    • Restores DSCP on ingress via tc ctinfo
    • Fully driven by SQM lifecycle hooks (start/stop)

  2. A read-only LuCI view: “DSCP Connections”

    • Real-time conntrack-based traffic view
    • Shows source/destination, ports, and protocol
    • Decodes DSCP classes (CSx / AFxx / EF)
    • Displays live PPS / BPS statistics
    • Purely observational (no traffic interception)

The DSCP Connections view works independently from SQM
and can be used to validate DSCP markings and CAKE DiffServ behavior.

This is NOT meant to replace SQM, fw4, or existing QoS solutions.
It is an experimental extension intended for:

  • latency-sensitive traffic analysis
  • DSCP validation
  • learning and testing purposes

Repository (early-stage):

Tested on OpenWrt 24.10+.

Feedback, design critique, and testing reports are very welcome.

1 Like
2

Hey, can you peek at qosmate and share your opinions where to improve it? Seems both are working in same direction :wink:

3

Consider trying to make this generic enough to be incorporated into sqm-scripts as a DSCP/ctinfo option.

4

Respectfully, I think sqm-scripts might take the "configure the required tc action ctinfo" part and maybe the "required nftables bits to store the egress DSCP into the conntrack database" but anything beyond that is IMHO clearly outside sqm-script's wheelhouse...

1 Like
5

Yes, that’s what I was thinking when I mentioned “generic”, but didn’t mention any specifics. After Qosify, DSCPClassify, QoSmate, and others, the market for such scripts is saturated (IMHO). Getting the basic ctinfo mechanism into sqm-scripts will allow people to setup regular fw4 rules to mark traffic with DSCP for basic usage.

We had a similar discussion before:

6

Thanks for the feedback, that makes sense and I agree with most of it.

My goal with this project was not to propose yet another competing QoS framework, nor to replace existing solutions like qosify, QoSmate, or fw4-based setups.

What I was trying to address is a slightly different angle:
• SQM (and luci-app-sqm) is already widely installed and familiar to many users
• Many users are uncomfortable writing custom nftables or fw4 rules
• There is often no easy way to observe whether DSCP markings actually survive end-to-end and are honored by CAKE

The custom SQM script and LuCI additions are therefore meant as a simple, opinionated workflow:
• define a small set of latency-sensitive endpoints (IPv4/IPv6)
• apply DSCP in a controlled way
• immediately validate the result via a read-only conntrack view

I fully agree that the generic ctinfo mechanism (store egress DSCP into conntrack and restore on ingress) could be useful as a reusable building block, possibly within sqm-scripts, while higher-level policy logic and UI probably belong outside of it.

For now, this project is mainly intended as:
• a learning and experimentation tool
• a reference implementation of ctinfo + DSCP + CAKE
• a convenience layer for users already relying on luci-app-sqm

I appreciate the discussion and pointers they help clarify where this fits in the broader ecosystem.

2 Likes