From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2.tohojo.dk (mail2.tohojo.dk [77.235.48.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 1D29B21F981 for ; Thu, 29 Oct 2015 08:40:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at mail2.tohojo.dk DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=201310; t=1446133247; bh=rKXfKFnhXXpC5DLDTw7wyCVpB8JFZFBUg255iX1yzt0=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=emQe/tHt9NXtCxeF8Qejo4IOIM0WpBGqGJfz74ScBzWI9aBx4AYrvRPXgN5O226u3 QvudH7Kzh35UBclBWTUhUsYKvaPA4fRjEg712eASollXqfC0jLcnDPpdrg59+/SSm0 HVeOQni+cMXsGH3nlH3omvPTu0frKem+8+gh/4pM= Sender: toke@toke.dk Received: by alrua-kau.kau.toke.dk (Postfix, from userid 1000) id C4335C402B1; Thu, 29 Oct 2015 16:40:46 +0100 (CET) From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= To: Sebastian Moeller References: <87twpaf0tq.fsf@toke.dk> <4B2F9D53-393D-44EC-8DC2-A59DFE0E6CBD@gmx.de> <87pozyf0cu.fsf@toke.dk> <87h9laey48.fsf@toke.dk> <6A01B7A9-BB31-4CF5-BE84-A54A2B860564@gmx.de> Date: Thu, 29 Oct 2015 16:40:46 +0100 In-Reply-To: <6A01B7A9-BB31-4CF5-BE84-A54A2B860564@gmx.de> (Sebastian Moeller's message of "Thu, 29 Oct 2015 12:20:32 +0100") X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87a8r1lm2p.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: cake@lists.bufferbloat.net Subject: Re: [Cake] memory X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2015 15:41:13 -0000 Sebastian Moeller writes: > Hi Toke, > > On Oct 29, 2015, at 12:02 , Toke H=C3=B8iland-J=C3=B8rgensen wrote: > >> Sebastian Moeller writes: >>=20 >>> 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; >>=20 >> 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 A= ND > potentially scary warnings if users configure something cake considers in= sane. > 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 c= ake > 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 =E2=80=9Chorrible mess=E2=80=9D 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