General Discussion of SQM

Looking at man tc-cake on a 4.19 system (Debian 10), I see

   DOCSIS Cable Overhead Keyword
       DOCSIS is the universal standard for providing Internet service over cable-TV infrastructure.

       In this case, the actual on-wire overhead is less important than the packet size the head-end equipment uses for shaping and metering.  This is specified to be an Ethernet frame includ‐
       ing the CRC (aka FCS).

            Equivalent to overhead 18 mpu 64 noatm

Case-insensitive searching an installed master build, the source of sqm-scripts, or that of Linux itself didn't turn up "docsis" for me.

Edit: /usr/sbin/tc so chasing that down now.

build_dir/target-mips_24kc_musl/linux-ath79_generic/iproute2-tc/iproute2-5.3.0/tc/q_cake.c:		} else if (strcmp(*argv, "docsis") == 0) {

What manual config entries would be needed to use "docsis" or the equivalent?

I add "docsis"/"docsis ingress" to the " Advanced option string for ingress" and also egress
tc - s qdisc shows that the overhead values are added

qdisc cake 8003: dev enp1s0 root refcnt 9 bandwidth 10Mbit besteffort triple-isolate nonat nowash no-ack-filter split-gso rtt 100.0ms noatm overhead 18 mpu 64 


On Debian

# Extra qdisc options ingress resp. egress

Seems like a "general approach" for options, given an examination of iproute2-5.3.0/tc/q_cake.c and

static int cake_parse_opt(struct qdisc_util *qu, int argc, char **argv,
                          struct nlmsghdr *n, const char *dev)

So especially the named keywords for per packet overheads are handled by tc, the kernel module really only deals with numeric overhead and mpu values. But since tc translates memes into values the running instance of cake really does not know whether you used
Cake DOCSIS or cake overhead 18 mpu 64. The other qdiscs in the kernel do not know about named keywords so sqm just exposes the numeric variables as these will work with cake and with htb/tbf and because in the end IMHO the overhead keywords are not necessarily a win, as it is typically not trivial to pick the right one (DOCSIS is the exception, but only if you ISP does not use ds-lite).

Hope that helps.


@moeller0. I totally agree. There are too many types of connections being provided to end users and companies alike to effectively narrow it down to "simple" word association.

A side note:
using cake with dscp set to prioritize syn acks(cs6) but send normal acks to bk(cs1) sure seems to improve my connection, even via WiFi. I can't provide any flent data but dslreports shows consistent bandwidth AND low bufferbloat with good sharing among the flows.


How do you measure the improvements? Syn ACKs should be classified as sparse by cake/fq_codel and hence given some boost (they only appear during connection set-up as the first packet in the "reverse" direction), so not sure why this improves things. Putting normal ACKs to BK will throttle them under load and potentially delay them more than keeping them in BE, which could result in slower "slow-start" for TCP connections which I could imagine makes like easier for our shaper (this might be different for flows using ECN).
In theory reverse ACKs should be processed in the same priority tin as the forward data flow for prioritization to be maximally effective, but it is well possible that using priority not as a per-flow property but as a functional property based on packet-type/class has some merit.

1 Like

I've only tried it over WiFi

openwrt 18.04
Linksys WRT3200ACM
ingress opts : (besteffort) dual-dsthost mpu 64 nat
egress opts : diffserv4 dual-srchost mpu 64 nat
iptables config:
iptables -t mangle -A PREROUTING -p tcp --tcp-flags SYN,RST,ACK  SYN \
-j DSCP --set-dscp-class CS6
iptables -t mangle -A PREROUTING -p tcp -tcp-flags SYN,RST,ACK ACK \
-j DSCP --set-dscp-class CS1

Tested using dslreports. My MAC hdd died and haven't replaced it yet, although I'm leaning towards also getting a laptop that fully supports linux for flent testing. Flent is broken for me using MAC OSX.

How? I use it on my macbook and I have most issues fixed, maybe I can help you (not that I want to affect you getting a linux machine :wink: )

So unless you serve a lot of data SYN-ACKs will come in over the internet, and hence will not profit from CS6 in cake. If your wifi uses WMM however they might be scheduled in the AC_VO class with the highest airtime access likelihood. But at the same time doing ACK deprioretization on the router for egress will have no effect on the wifi link (but should be visible to cake, resulting in the throttling under load effect I hypothesized about above).

That's why I'm posting it! lol. I have NO concept of the logic behind WHY it works, it just does :wink:

And I am not doubting that it works, I just try to understand the how and why :wink:

Same here, I was hoping you guys had a clue as to why :rofl: I'm stumped.

An update for a gaming capture using tcpdump for those who may be interested The game is Call of Duty Black Ops 3 ( Released November 6, 2015 ). I filtered on the specific udp source port of 3074 FROM my Sony Playstation v4 which in turn has varying destination ports to each of it clients including the game server. I can email the capture later if someone is interested.

Average packet size 195 bytes
Packets per second 68
bandwidth used 106,080 kbits per second
1 packet every ~15ms

Interesting, that looks similar to VoIP traffic in rate and packet-size. Would be interesting to know how much traffic flows in the reverse direction during game play, and at what rate....

Statistics for Inbound Packets

Measurement Captured Displayed Marked
Packets 9332 3340 (35.8%) β€”
Time span, s 102.339 101.173 β€”
Average pps 91.2 33.0 β€”
Average packet size, B 236 373 β€”
Bytes 2202339 1245639 (56.6%) 0
Average bytes/s 21 k 12 k β€”
Average bits/s 172 k 98 k β€”

Statistics for Outbound Packets

Measurement Captured Displayed Marked
Packets 9332 6882 (73.7%) β€”
Time span, s 102.339 101.220 β€”
Average pps 91.2 68.0 β€”
Average packet size, B 236 195 β€”
Bytes 2202339 1343480 (61.0%) 0
Average bytes/s 21 k 13 k β€”
Average bits/s 172 k 106 k β€”

I'm filtering here by port 3074 which is the data port for all communications between the servers and other players for PS4

Those are typical game or VOIP type flow rates. A few hundred kbps at most with a packet 20 to 100 times a second.

The codel type calculations are useless for UDP traffic, as there is no tcp type feedback. Most likely games like this send UDP packets on a schedule to provide game state updates as well as some extra packets to negotiate irregular events, like new players joining or scenery changes or whatever.

Generally SYN or ACK packets being TCP probably your rule does something that essentially up prioritizes your UDP traffic relative to TCP. Perhaps it slows the slow start causing less choking of the UDP because the TCP never gets the full bandwidth.

1 Like

Sounds plausible.
Note game traffic is bursty and the max packet never seems to go beyond 1322bytes in length {1280b + 20b (ip header) + 14b (ethernet type II header) + 8b (UDP header) }. It's a small percentage but can still cause H.O.T.L blocking.

I am using a R7800 with some Performance tweaks on owrt 19.07-rc2 currently. What i ask myself is if i will get any performance increase out of my router when using sqm? Bufferbloat Testing on gave me straight A's already without SQM enabled. (BW: 250/25)