Re: [Cake] Fighting bloat in the face of uncertinty

[Jonathan Morton <chromatix99@gmail.com>]

> On 8 Sep, 2019, at 3:03 am, Justin Kilpatrick <justin@althea.net> wrote:
> 
> So you believe that setting the target RTT closer to the path latency was not the main contributor to reducing bloat? Is there a configuration I could use to demonstrate that one way or the other? 

The second-order effect I mentioned is related to the 'target' parameter.  Checking the code, I am reminded that while Cake itself can have 'target' set from userspace, there actually isn't a parameter to the tc module which allows setting it independently of 'rtt'.  But there *is* a table in q_cake.c (in tc) which you can temporarily extend with the following entries for experimentation:

static struct cake_preset presets[] = {
	{"datacentre",		5,		100},
	{"lan",			50,		1000},
	{"metro",		500,		10000},
	{"regional",		1500,		30000},
	{"internet",		5000,		100000},
	{"oceanic",		15000,		300000},
	{"satellite",		50000,		1000000},
	{"interplanetary",	50000000,	1000000000},
+
+	{"metro-loose",		5000,		10000},
+	{"internet-tight",	500,		100000},
};

If the effect is genuinely due to marking rate, then 'metro-loose' should behave like 'metro' and 'internet-tight' should behave like 'internet', to a first-order approximation.  If, on the other hand, it's due to the second-order interaction with CPU scheduling latency, the reverse may be true.  The latter is not something you should be counting on, as it will insert random AQM marking even when the link is not actually saturated.

You could also set it back to 'internet' and progressively reduce the bandwidth parameter, making the Cake shaper into the actual bottleneck.  This is the correct fix for the problem, and you should notice an instant improvement as soon as the bandwidth parameter is correct.

 - Jonathan Morton