toke at toke.dk
Thu Oct 29 11:40:46 EDT 2015
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.
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
More information about the Cake