fq_codel/CAKE stories?

[dtaht]

I agree with you that if your nearest CDN is less than 30ms away - and you aren´t trying to communicate worldwide, that regional is a good setting.

Am I not gambling that my furthest commonly-used CDN is less than 30ms away, and that the consequences of being wrong occasionally are minor?

However, the ack-filter on rx is largely useless and eats cpu. You only need it on tx in your environment.

That’s insightful, thanks. I’ve not only removed that useless bit from the config, I added this paragraph:

“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, 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.”

Yes, the chances of being wrong occasionally are very minor. It is better, especially, when inbound shaping, to be using your typical RTT as the estimate so as to get control of the queue before it flows into the isp shaper you are defeating.

The codel algorithm was designed to scale to worldwide RTTs (280ms) with its default settings of target 5ms, interval 100. It was also designed so that a single TCP flow could use up nearly all the bandwidth, so long as the RTT was in that range. The most common use cases nowadays is 15 short flows from a web browser, 5 or more from torrent, and in general interactive flows like voip and videoconferencing use so little bandwidth that they never see a drop.
With lots of flows, and/or short rtts in general codel isn´t actually responsive enough.

A case where using the regional RTT might hurt (30ms interval, 1.5ms target) is where a single packet takes longer than the bandwidth to “fit”. At 10Mbit, a single packet fits into 1.3ms.

Since the development of codel, linux based hosts have adopted packet pacing which tends towards working better at short and long ranges. I haven´t got any real benchmarks of such however.

Anyway, unless if you are in a case where you have to transmit lots of data over a single flow, somewhere further than 100ms away, and you have > 10Mbit/s bandwidth, the regional setting should be fine.

…

“We do this on the cake-tx side alone when we have a greater than 10x1 download/upload ratio, on the narrow end of an asymmetric pipe, where the acks from a single TCP flow can saturate the upload. Ack-filtering does not do any good for encrypted traffic - as with a site-to-site WireGuard tunnel. Acks will almost never be queued on the rx side, there is no point it attempting to filter there.”

"