Re: [Cake] memory

["Toke Høiland-Jørgensen" <toke@toke.dk>]

Sebastian Moeller <moeller0@gmx.de> writes:

> Hi Toke,
>
> On Oct 29, 2015, at 12:02 , Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>
>> Sebastian Moeller <moeller0@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.

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.

> The current set of named rtt-target combinations for example seem to
> gotten it slightly wrong...

Not a big fan of those either.

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

-Toke