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).
docsis
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?
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).
@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.
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.
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).
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....
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.
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 dslreports.com gave me straight A's already without SQM enabled. (BW: 250/25)
)
I'm stumped.