From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id ED34521F8FC for ; Fri, 30 Oct 2015 02:13:22 -0700 (PDT) Received: from u-089-d061.biologie.uni-tuebingen.de ([134.2.89.61]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MGjfl-1ZeZDS3W7N-00DWwt; Fri, 30 Oct 2015 10:13:19 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sebastian Moeller In-Reply-To: <87a8r1lm2p.fsf@toke.dk> Date: Fri, 30 Oct 2015 10:13:16 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2E05CB23-D755-414E-86BB-A69C928D321F@gmx.de> 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> <87a8r1lm2p.fsf@toke.dk> To: =?windows-1252?Q?Toke_H=F8iland-J=F8rgensen?= X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:y2zn1XNCIPk9vMCvEAjkjkiJ4M1ncKeB6KKFQb1DurzZqYIbMLD Wc1hhQMankhmjiuAioR2WV1u9f9Yl3xFXJbY6D4FR3gpIkPXAiTfJP8oA45RU7RUm0lZk3J x83Iy6Szl/kZRPxA9cENzX6nrfBC32NvkquUtx8CIMg0JJJB909qNcRHQVD7Qih3awcR0vC wcYQGlo268h+gXg6Clhrw== X-UI-Out-Filterresults: notjunk:1;V01:K0:syxSwUtmNeQ=:NVRGJrELLiCUyL3x5+RkHv ms7Dh3ONZmNGdDoEWWMKZZ9yYMKsmuFuwUqF6XMbi95LC9+0Ie85E896zFzh92UBSZqtz7k6e ppFTncThCCwX6V0yLG12ofOy5z4fqyTkz10MRwDCBvKRq7O88axUctZZwGD5+5u425R0MICCt +lV20ebLRO2k/SC5OizHOIvLi4pJpkmlORwD4hcdXIEoebq9gnOlCQXy+Kbd4byTkR8i0PUrz /158/J5CBcTXPy5f6TMK9WZaumUWYb7RFTN9noeGtTdn/0n3Mr2gMqsWRwM+wZVOR1RTf9pDM +tr+AJ/wQWP/ZfJSQWJ+/Nu6SJHUPPJty/cWLYn2i5wG2vw9M5B46bhvz1w1EhMvjPhnNhUPe lHvXDol5F9MYEP0NjtnUwS0gf+kpAlKmqK9Kc2RgrYKmtlIeaGM1L2SfEI4cMU4D6HKrj/FAp V6EwPhuP+RjbuIFg7AwODLmNYcUCQ+uyFP/UydNLt4h06PVlG66SP2E+CSKzMb30ne9r5kgTj uciVt/PkPZxy6ls0knWPZnBUg9iWlB+OtU8XDp9LdO/vi7Sd/O1Br3yROGsFkbWXb1S5mHfYe OxwhDv6sCVKZa0jpVtC75ekwIto01VyRL0sV8apHNZ/r9K9pjFevI5/AdOqWR3TYRX/jYCsFN iI9hk5cijO6P5/pEpmO8iWxEwU0N2J8pdePFpjbev9K3D3l0C0NcxAqXwbbOoAziWVnuy7Ufq FR5gy+bn50CQE0Jt62jp3YB6U6evNChOy2Z97T1GsAwEkEuNniZWfITZNHxZOg7f/Ym8dXnHH 5zDNJ6a 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: Fri, 30 Oct 2015 09:13:45 -0000 Hi Toke, On Oct 29, 2015, at 16:40 , Toke H=F8iland-J=F8rgensen = wrote: > Sebastian Moeller writes: >=20 >> Hi Toke, >>=20 >> On Oct 29, 2015, at 12:02 , Toke H=F8iland-J=F8rgensen = wrote: >>=20 >>> 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. >>=20 >> 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? >=20 >> We avoid the =93horrible mess=94 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). >=20 > 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=85 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 = =93should not need to touch as the defaults are sane=94 in my view ;) >=20 > 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...) >=20 >> The current set of named rtt-target combinations for example seem to >> gotten it slightly wrong... >=20 > Not a big fan of those either. To play devil=92s 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 ;) >=20 >> 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 ;) >=20 > 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 >=20 > -Toke