[Cake] A few puzzling Cake results

[Jonathan Morton]

>>> 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