[Cake] memory

[Dave Taht]

I am scarred by nearly every academic paper even semi published,
mucking with the target, rather than interval parameter. I really
think the evidence is conclusive we do not need to expose the target,
only the interval. Target should be a calculated value, always, in
particular adjusted to 1MTU, and in a range from 5-10%. I had done
much testing at the (interval >> 4) 6.2% figure which seemed to
interact with the cable mac mildly better (6ms acquisition time) back
in the day.

PS: I do not think we have ever done enough analysis of tcp window
sizes in captures in the rrul and heavier duty tests to understand
fully the actual latencies and loss tcp flows experienced.


Dave Täht
I just invested five years of my life to making wifi better. And,
now... the FCC wants to make my work, illegal for people to install.
https://www.gofundme.com/savewifi


On Fri, Oct 30, 2015 at 5:13 AM, Sebastian Moeller <moeller0 at gmx.de> wrote:
> Hi Toke,
>
> On Oct 29, 2015, at 16:40 , Toke Høiland-Jørgensen <toke at toke.dk> wrote:
>
>> Sebastian Moeller <moeller0 at gmx.de> writes:
>>
>>> Hi Toke,
>>>
>>> On Oct 29, 2015, at 12:02 , Toke Høiland-Jørgensen <toke at toke.dk> wrote:
>>>
>>>> Sebastian Moeller <moeller0 at gmx.de> writes:
>>>>
>>>>> Yes, while trying to be funny I glossed over that part a bit (the
>>>>> loooong RTTs part was aiming at that), sorry. But really I am wonder
>>>>> what it is that makes my position that cake should expose and honor a
>>>>> packet limit for its queueing so controversial;
>>>>
>>>> The suggestion in itself is not necessarily controversial. However, the
>>>> road to bloated interfaces is covered in good intentions. Each addition
>>>> may be worthwhile in itself, but the sum of them becomes a horrible mess
>>>> to configure (I'm being a bit hyperbolic here, but I'm sure you get my
>>>> gist). So I'd rather say that for each possible configuration variable,
>>>> we should figure out if there is a way to avoid exposing it, and only
>>>> exposing it if we can't find a way to do that. Rather than going with
>>>> the "easy" solution of just making it configurable and leaving the user
>>>> to figure it out.
>>>
>>>      I am all for empowering the users to change the settings (well, the few
>>> settings we talk about here, target, interval, limit, encapsulation and
>>> overhead, I believe bandwidth and diffserv-scheme not contentious ;) ) in
>>> COMBINATION with having sane defaults that make twiddling not necessary AND
>>> potentially scary warnings if users configure something cake considers insane.
>>> Exposing parameters that by all probability will not go away does not seem
>>> dangerous to me, but the right thing to do. I venture the guess that if cake
>>> should give up using codel underneath it is time for a rename, and cake2 or
>>> cookie can have different exposed parameters than cake, no?
>>
>>>      We avoid the “horrible mess” part by basically requiring none of
>>> the parameters (or just few if none is impossible) to be specified and
>>> fill in all not specified parameters using the current auto-setting
>>> methods. I am fine with not exposing implementation details, but the
>>> parameters that will stay with us until we change the algorithms like
>>> target and interval should be exposed (unless we are dead certain that
>>> our automatic methods will configure the objectively best parameters
>>> for all conditions).
>>
>> Well, that's the thing: It is not clear to me that limit and target are
>> not exactly that: implementation details.
>
>         I guess we can agree to disagree, from my vintage point interval and target are the two core tunables that the codel mechanism cake builds upon uses and exposes; so with cake being in some sense a successor of fq_codel, I see no reason why exposing those will cause legacy issues. As already said if we switch away from codel under the hood there is no reason to keep the cake name and the parameters. Limit however absolutely needs to be exposed as there is no real way to divine the optimal limit for each deployed instance, given that some of the variables in the optimization space are most likely not available to cake (think a memory reserve the user might require to run another application on the router), or to come back to our example, a user on a high bandwidth satellite link but struck with a puny router might still prefer to sacrifice some good put if that helps avoid un-planned reboots… Or put differently limit is a policy parameter and hence should be exposed to the user; and in a sense so are is the target to interval ratio, according to the codel RFC this controls the bandwidth sacrifice and the resulting median queuing delay, which are also policy decisions the user should be able to control.
>         Again "should be able to control" is not incompatible with “should not need to touch as the defaults are sane” in my view ;)
>
>
>>
>> Note that I did say we should be sure that they are, and I'm not sure we
>> are quite there yet. But I do believe that we should first make
>> absolutely sure that these are parameters that are not better
>> calculated, before deciding to just expose them to the user.
>
>         I believe these two thanks are rather orthogonal, the beauty of exposing these is that it will allows us more leeway in changing the defaults later on (I believe after upstreaming even changing defaults results in discussions whether that does not catch current users by surprise...)
>
>>
>>> The current set of named rtt-target combinations for example seem to
>>> gotten it slightly wrong...
>>
>> Not a big fan of those either.
>
>         To play devil’s advocate, in the ideal case they will make configuring cake simpler: user on a 10Mbps satellite link might just use:
> sudo tc qdisc add dev eth0 root cake bandwidth 10Mbit satellite
>         as compare to a potential alternative:
> sudo tc qdisc add dev eth0 root cake bandwidth 10Mbit rtt 1000ms target 62.5ms
>
> Prtesonally I would prefer the second, but I like numbers ;)
>
>>
>>> I am all for not leaving the user to figure it out, I just argue for
>>> making it possible to do something we had not thought about; I believe
>>> hindsight is 20/20 not fore-sight ;)
>>
>> Well, if we add a parameter we can't remove it later, because it then
>> becomes part of the stable API. Whereas adding a new parameter later
>> *is* possible.
>
>         I totally buy this argument; all I question is do we really see cake switch away from using codel underneath? If not then exposing target and interval should do no harm. And limit is something all qdisc should require by law ;) (I believe most actually honor this already). Please note that I do not propose to expose variables to modify the different diffserv schemes, I am totally fine with those being hard coded ;)
>
>
> Bet Regards
>         Sebastian
>
>>
>> -Toke
>
> _______________________________________________
> Cake mailing list
> Cake at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake