Motivation
Applying some type of queuing to your Internet uplink can greatly help with bufferbloat, a phenomenon that adds increasing latency as the link becomes saturated. The easiest of these to configure on RouterOS is CAKE, but there are a lot of options to consider and not much guidance from the official docs.
In this article, I will explain this seemingly simple configuration:
/queue type
add kind=cake \
name=cake-rx \
cake-diffserv=besteffort \
cake-flowmode=dual-dsthost \
cake-rtt-scheme=regional \
cake-nat=yes
add kind=cake \
name=cake-tx \
cake-ack-filter=filter \
cake-diffserv=besteffort \
cake-flowmode=dual-srchost \
cake-rtt-scheme=regional \
cake-nat=yes
/queue simple
add name=queue1 \
max-limit=256M/24M \
queue=cake-rx/cake-tx \
target=ether1
This yields an A+ result on the Waveform Bufferbloat test with my Xfinity cable Internet connection.
Speed Limits
I’m not going to cover the configuration in the order given above, because the most important setting is near the end: the max-limit on the simple queue. I’m currently getting a connection from my ISP which their marketing department claims to give “Download speeds up to 300 Mbps!” And, yes, on a speed test without CAKE enabled, I can peak up into the 350 Mbit/sec range. Problem is, latency becomes terrible.
My ISP doesn’t make any claims about upload speed, but similar tests show a burst speed limit of around 26 Mbit/sec here.
Why do I limit it, then? Easy: because if I go any higher than this, my excess latency numbers on the Waveform test start increasing from the perfect 0 ms value I’ve got it dialed into now. I’m willing to give up my burst rates to get more predictable latency.
You will almost certainly have to adjust these values to match your own local Internet performance. I suggest trying the Waveform test with CAKE disabled to get a baseline, then set these values a smidge below the ideal ones reported. Keep reducing them until you get your excess latency down into the single-digit milliseconds range. There’s no especially good reason to shoot for zero, but if you can afford the peak speed loss, why not?
It is possible to use a single CAKE queue for both transmit and receive, but I’ve chosen to make use of the cake-flowmode parameter to give different behavior for sending versus receiving.
There is one additional important detail you have to keep in mind: the bandwidth limits are given from the target interface’s perspective, not that of your client. We are used to specifying asymmetric Internet bandwidths like these in terms of the client perspective, but that will give you an upside-down view of the way RouterOS queues work. WinBox will tell you that my “Target Upload” speed is 256M and my “Target Download” speed is 24M, which feels wrong until you realize that when I download something to my client computer, I do so by making the WAN interface upload that traffic to my client.
Interface and Address Targeting
The simple queue we’re attaching the CAKE shaper to needs to know which flows it should apply to. You don’t want it throttling your LAN’s 10G backbone, and there’s likely no need to shape local WiFi separately from outbound Internet traffic. It is for this reason that my setting above targets my WAN interface, shown here as the common ether1 default.
For a typical home Internet gateway, you do not want to set a dst address value instead of or in addition to the target interface. RouterOS isn’t flexible enough to let you target everything but the LAN by address rules alone, for instance. Targeting the WAN interface is simpler.
ACK Filtering
The purpose of the cake-ack-filter=filter setting on the cake-tx queue is to reduce the overhead of TCP ACK packets by removing ones not strictly necessary. TCP was designed with symmetric network speeds in mind, but with modern 10:1 or worse splits, it becomes important to reduce unnecessary upload traffic. My nominal 300/20 connection is 15:1, and even under the more stringent speed limits I assign above, it’s still running at a nearly 11:1 ratio.
If you’re lucky enough to have a symmetric Internet link, you might not need this.
If you’re like me from about a year ago, when Xfinity was giving me a 100/5 connection — 20:1! — you might need to set it to ack-filter-aggressive to get the best results.
We do this on the cake-tx side alone because in typical cases, we can only control what we send to remote TCP/IP stacks, not what they do in turn. There are exceptions to this, as with a site-to-site WireGuard tunnel where the queue is applied to the decrypted end of the tunnel,1 but even in that case ACK filtering has its most useful effect on the narrow side of an asymmetric pipe. Consequently, the best strategy is to do this ACK filtering on each peer’s Tx side alone, improving the remote site’s Rx queuing from afar.
Round-Trip Time
The cake-rtt-scheme=regional setting may surprise you. Why not set it to “internet”?
The reason is that these are heuristic values based on general assumptions. What “internet” actually means in this context is a 100 ms ping time, as if we still lived in a world where you could reasonably be contacting servers across the globe regularly.
CDNs changed this. Even if you live outside the US and are regularly making heavy use of Silicon Valley services, there’s a good chance that your clients are actually connecting to a CDN datacenter somewhere on your continent. If you live in the US, the chance of your traffic going off-shore is increasingly small as services consolidate into CDNs and top-tier hosting providers.
With my ISP’s unloaded ping time of around 25 ms, I chose the “regional” mode, which sets the RTT to 30 ms, the closest match I could achieve without resorting to the custom “rtt” option.
Best-Effort Diffserv
Differentiated services is the practice of setting marks on various types of data flows, to allow the router to give preferential service to certain types of traffic. A common scheme is to give VoIP calls first-priority access to the bandwidth, then video conferencing, then gaming, and then to dump everything else into a bulk-download bucket.
Since I don’t bother with any of that cleverness here on my home LAN, I tell CAKE to try its best without any hints from me. It works well in my testing.
Enabling any of the diffserv* options without actually applying the related markers burns CPU time to no useful end.
NAT
CAKE has a mode for accommodating NAT addressing, cake-nat=yes in RouterOS-speak. If you use NAT, enable this. If not, then don’t.
Fast-Tracking
For all of the above to take effect, you must modify the default “fasttrack” rule in the IPv4 firewall. Fast-tracking causes flows to bypass the CPU, which is bad for CAKE since it is implemented by the Linux kernel and thus runs purely on the router’s CPU. You have several paths out of this trap:
Disable it. This is fine for testing, but be sure your testing is complete before calling it good.
Remove it. Do this only if the router you’re applying this CAKE shaping to doesn’t need fast-tracking for LAN traffic.
Retarget it. Because I am the sort to run LAN-only
iperf3tests across my router’s bridge, I prefer leaving this rule enabled but changed:/ip/firewall/filter add action=fasttrack-connection chain=forward \ connection-state=established,related \ comment="fasttrack LAN traffic only" \ out-interface=!ether1 \ in-interface-list=LAN \ hw-offload=yesThis allows CAKE to take effect for Internet traffic without affecting traffic crossing the router’s LAN-side bridge.
RouterOS will be getting IPv6 fast-tracking in version 7.18, but until that's installed and set up where you are, failing to make one of the above choices can lead to a difficult-to-debug problem in testing where your bufferbloat tests are great one day and terrible the next. What is likely happening here is that your client is ping-ponging between IPv4 and IPv6 addresses for the server based on round-robin DNS behaviors. That in turn affects the queue’s ability to do the job you gave it by creating a hidden toggle for fast-track mode.
References
Dave Taht’s thread “some quick comments on configuring cake” on the MikroTik forum is well worth reading.
License
This work is © 2024-2025 by Warren Young and is licensed under CC BY-NC-SA 4.0
- ^ Otherwise, CAKE's ACK filtering can no effect since WireGuard is a UDP protocol, and any TCP headers inside the tunnel are encrypted.