"no-ack-filter " and "( marks defaults)" indicates that ack filtering is not the default behaviour, so if you want to try it (which might be a good idea on a very asymmetric link like a typical DOCSIS link) just add it to the advanced option string for egress.
The keyword ack-filter on egress doesn’t implement. I’ve tried defaulting, downloading another copy of the firmware, even ack-filter by itself. It only become activated for the development releases.
Well 17.01.4 was released in October 2017, and ack-filtering hit the sch_cake repository first November 12th 2017. I would say this is more a case of unfortunate timing and not really a bug. I believe that the updates to the tc package will be shared by stable releases and master while the actual version of the kernel modules is specific to each individual branch.
EDIT: Actually @ldir updated both the kernel module as well as iproute2 on December 15th, so it seems clear why 17.01.4 does not have the updated kernel module, but I agree that is seems odd that it seems to have the updated iproute2 binary? On the other hand following https://downloads.lede-project.org/releases/packages-17.01/mips_24kc/base/ contains a tc package built on December 30th that does contain the string ack-filter (but packages does not contain a cake package as expected), so I still assume that there no real bug, just a somewhat odd partial update situation. But mind you the current openwrt snapshots do contain both a recent looking sch_cake and tc binary:
root@router:~# tc qdisc replace root dev eth0 fq_codel
root@router:~# tc -s qdisc show dev eth0
qdisc fq_codel 801d: root refcnt 2 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 4Mb ecn
Sent 36044 bytes 254 pkts (dropped 0, overlimits 0)
maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0
new_flows_len 0 old_flows_len 0
root@router:~# tc qdisc replace root dev eth0 cake ack-filter
root@router:~# tc -s qdisc show dev eth0
qdisc cake 801e: root refcnt 2 unlimited diffserv3 triple-isolate ack-filter rtt 100.0ms raw total_overhead 14 hard_header_len 14
Sent 11695 bytes 99 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
memory used: 2432b of 15140Kb
capacity estimate: 0bit
Bulk Best Effort Voice
thresh 0bit 0bit 0bit
target 5.0ms 5.0ms 5.0ms
interval 100.0ms 100.0ms 100.0ms
pk_delay 0us 10us 11us
av_delay 0us 2us 0us
sp_delay 0us 2us 0us
pkts 0 95 4
bytes 0 11047 648
way_inds 0 0 0
way_miss 0 85 1
way_cols 0 0 0
drops 0 0 0
marks 0 0 0
ack_drop 0 0 0
sp_flows 0 6 1
bk_flows 0 0 0
un_flows 0 0 0
max_len 0 447 194
root@router:~# tc qdisc replace root dev eth0 fq_codel
root@router:~# tc -s qdisc show dev eth0
qdisc fq_codel 801f: root refcnt 2 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 4Mb ecn
Sent 12891 bytes 90 pkts (dropped 0, overlimits 0)
maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0
new_flows_len 0 old_flows_len 0
root@router:~# uname -a
Linux router 4.9.77 #0 Sat Feb 3 08:52:11 2018 mips GNU/Linux
root@router:~# cat /etc/banner
_______ ________ __
| |.-----.-----.-----.| | | |.----.| |_
| - || _ | -__| || | | || _|| _|
|_______|| __|_____|__|__||________||__| |____|
|__| W I R E L E S S F R E E D O M
-----------------------------------------------------
OpenWrt SNAPSHOT, r5994-fd30187c87
-----------------------------------------------------
So maybe just try a snapshot if you want to test ack-filtering?
Side note:
ACK-filtering basically uses the redundancy in an ack stream to remove (some of) the superfluous ACK packets thereby noticeable reducing the bandwidth consumed by the traditional one ACK packet for every two full MTU packets, which especially at high bandwidth seems somewhat overly redundant. But, IMHO it should be the endpoints of a flow that negotiate "sane" behaviour and it should be the transports responsibility to not second-guess the endpoints (and if all flows are given a fair share of the available bandwidth in the end it is the endpoints of a specific flow that would pay a price for overly chatty ACK traffic).
That said, on links with extreme asymmetry it still might make sense to instruct one's router to perform ACK-filtering simply because it sometimes is impossible to make all endpoints behave sanely. Also a number of especially DOCSIS ISPs are known to perform ACK-filtering without end-user control already (but typically only after the modem actually encounters a standing queue, something that running SQM effectively makes quite improbable). In that light a link with SQM will show worse Upstream bandwidth under downsstream saturation than without SQM; and users afflicted with this situation might want to consider instructing SQM to filter ACKs.
Tl; dr: ack-filtering is an interesting technology for a few specific use-cases, but it is not clear that this is a candidate for new default behavior for cake...