[Cake] Running Cake at long RTTs

[Sebastian Moeller]

Hi Toke,

On Oct 28, 2015, at 17:34 , Toke Høiland-Jørgensen <toke at toke.dk> wrote:

> Sebastian Moeller <moeller0 at gmx.de> writes:
> 
>> Hi Toke,
>> 
>> On Oct 28, 2015, at 16:36 , Toke Høiland-Jørgensen <toke at toke.dk> wrote:
>> 
>>> Sebastian Moeller <moeller0 at gmx.de> writes:
>>> 
>>>> Except I requested rtf 120 ms and got 122.7, which admittedly is
>>>> close. I know I repeat myself, but on of the is one things that
>>>> irritate me in software is if software silently pretends to know
>>>> better… Now 122.7 versus 120 might be in the noise, but look at that:
>>> 
>>> I don't remember from where, but I suspect there's something wrong with
>>> the 'change' logic in Cake. Can you try removing the qdisc completely,
>>> then re-adding it, rather than doing a straight replace?
>> 
>> Good point:
>> moeller at happy-horse:~/CODE/sch_cake> sudo tc-toke qdisc replace dev eth0 root pfifo_fast
>> moeller at happy-horse:~/CODE/sch_cake> sudo tc-toke qdisc replace dev eth0 root cake bandwidth 1Mbit besteffort rtt 100ms ; sudo tc-toke -s qdisc
> 
> Right, so there's definitely a bug in the 'change' logic.
> 
>> Just 95 is not equal to 100 either…
> 
> That's also a bug as far as I'm concerned.
> 
>> At least in full automatic mode I would have assumed cake would also
>> increase the interval according to the available bandwidth in the
>> different Tins...
> 
> What has the interval got to do with the bandwidth? There's definitely
> some value in capping the target to be at least the time it takes to
> transmit one MTU's worth of data.

	Well according to codel’s theory target shall be between 5 to 10% of interval (I note this range is not deduced mathematically and so 1/8 probably is well enough as is 1/16, heck even 1/32th might still be good enough). So if we increase target we also should accordingly increase interval to keep the relation correct. I believe your tests at long RTTs have just shown that the theory is not completely off. So I am willing to entertain the notion that adapting to slow bandwidths should have an effect on target and interval… 


> 
>> All the additional parameters are there to tweak and experiment. So I
>> argue exposing knobs is not making it difficult to configure as long
>> as nobody needs to touch these (I also volunteer to make the tc help
>> more specific in that regard…)
> 
> If no one needs to touch them, why are they there? At best that will
> just make things break when they bitrot.

	Do you really envision lots of changes to cake after upstreaming, as otherwise things should pretty much stay as well debugged as when upstreamed: "no change no bitrot” or so. But the point for exposing it that your experiments have shown that the automatic defaults did not do the right thing, are we really sure that we tested all relevant combinations of the parameter space to say, we are done, the target interval relation is solved?
	Note I am fine with exposing some parameters only if the user also adds a silly option like “willing_to_keep_the_pieces_if_cake_breaks” or is it crumps...

> 
> I can see how getting around the need for the encapsulation variables is
> going to be hard;

	Numeric overhead is all that is needed ;)

> but for the target, I am not sure I see the value in
> exposing this for "experimentation”.

	But so far we have not gotten it right, so experimentation was/is still required.

> If we are sure that the relation
> between target and interval should be fixed (and I'm not entirely
> convinced of that yet, but will think about it some more), then exposing
> target is just going to enable invalid configurations.

	No, unreasonable maybe but not invalid; I am fine with cake not accepting target > interval which I admit is invalid, but target = interval/2 is valid no matter whether I think it is reasonable. If we go the “I know what is best for you route” we should be really really certain that we actually do. But do we? The fact that we are having this discussion makes me wonder a bit.
	The codel RFC give some guidance on the relation of interval and target for TCPs (https://datatracker.ietf.org/doc/draft-ietf-aqm-codel/?include_text=1 Section 3.2) but we so far  cake does/did not follow this guidance, arguably recent cake was doing the wrong thing, exposed interval and target would have made it possible for people using deployed sch_cake’s to fix the behavior. Currently the only redress is to edit the source and build the module afresh, certainly outside the scope of cake’s “make common things simple” motto, no?


Best Regards
	Sebastian

> 
> -Toke