[Cake] A few puzzling Cake results
chromatix99 at gmail.com
Thu Apr 19 05:55:37 EDT 2018
>>> your solution significantly hurts performance in the common case
>> I'm sorry - did someone actually describe such a case? I must have
>> missed it.
> I started this whole thread by pointing out that this behaviour results
> in the delay of the TCP flows scaling with the number of active flows;
> and that for 32 active flows (on a 10Mbps link), this results in the
> latency being three times higher than for FQ-CoDel on the same link.
Okay, so intra-flow latency is impaired for bulk flows sharing a relatively low-bandwidth link. That's a metric which few people even know how to measure for bulk flows, though it is of course important for sparse flows. I was hoping you had a common use-case where *sparse* flow latency was impacted, in which case we could actually discuss it properly.
But *inter-flow* latency is not impaired, is it? Nor intra-sparse-flow latency? Nor packet loss, which people often do measure (or at least talk about measuring) - quite the opposite? Nor goodput, which people *definitely* measure and notice, and is influenced more strongly by packet loss when in ingress mode?
The measurement you took had a baseline latency in the region of 60ms. That's high enough for a couple of packets per flow to be in flight independently of the bottleneck queue. Therefore, the most severe effects of fq_codel's configuration (and Cake's old configuration) are less obvious, since TCP is still kept operating in a regime where its behaviour is vaguely acceptable. Aggregate goodput remains high anyway, due to the large number of flows involved, but I would expect the goodput of individual flows to show odd behaviour under fq_codel.
I would take this argument more seriously if a use-case that mattered was identified. So far, I can't even see a coherent argument for making this tweak optional (which is of course possible), let alone removing it entirely; we only have a single synthetic benchmark which shows one obscure metric move in the "wrong" direction, versus a real use-case identified by an actual user in which this configuration genuinely helps.
And I've tried to explain why I believe this to be the Right Thing to do in general, contrary to Dave's opinion.
- Jonathan Morton
More information about the Cake