From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 1944021F2F1 for ; Fri, 30 Oct 2015 05:21:52 -0700 (PDT) Received: from u-089-d061.biologie.uni-tuebingen.de ([134.2.89.61]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0M1iGk-1akfFX1gLK-00tkvs; Fri, 30 Oct 2015 13:21:49 +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: Date: Fri, 30 Oct 2015 13:21:49 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <22E6EBEB-E103-4953-BF1B-6DC6A9914EE2@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> <2E05CB23-D755-414E-86BB-A69C928D321F@gmx.de> To: =?windows-1252?Q?Dave_T=E4ht?= X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:jNj822ORVEvyLMYUuVgFA6PLTwyOlldxo/ogfycEx/p793JmqYn YCg/GL1Xsuf2K+J7rk1O4av1pAAGT63kNtDuyjVfoWKX5Eqs+J5r2RFJmnFsRz7WzjHk12t 1i/FC1NnaUBudjhr9hmHrWna4WUz7kzvmTxO0fDFMlD48FKlwSKy9Oxs5X8L4QIkZNjzGD8 a9twrdO65XyoANPIGxrnw== X-UI-Out-Filterresults: notjunk:1;V01:K0:COcNIXyIbuM=:UaZuDZxP+O6wd4iatP+6VC l2Meuj0/a22o7FDXXGxF3iIHouVAd9zInALGiDlQhdRnxCWNXCjjnUPYOqOv+atQ3y31wNUsS 1Z6Ky9gvOVz38IgHg+E7PWo/b2Sw23SYomD1DgliItHGVgsl7AF/L9E1gLa1Wp08TqmpFmRdc 2sgjsH6Ua8IP3yaCOBtQyaBvnvAlsd3hECno5p0z+isTz+tJW3u+yGyAnBeGmznAYOvvtK2N6 k5vI9/9x1/pQiMokgki+wlUlVSX0ZkPz27KtXGxEZj435IPYW5HCw/76esK6w1iOecdklfDKQ kEGxCXGAzy+c6A+gmgdZwlGlUowVXHWrsgRpOMEDBEKKUz+JUCUbLDay1DCmaPLnKwBbqVPep a4cdBTZPc4UMFlfpwXoSjxyv1qYYZFjXUefNLSwzXIDntfPq0Dv9lxLVb/E7mb/qiIlLwKhVO jiUzvw+VZyCmBsHXPE6XWNtFTGMo5ex7A95BgPcte2trX4qjewuEwZzuvChcVlWi9I5rcot3a d/dZ/oMAyZHNRx92M5vr+QU8gUR8VGZJiCH89ayNvfIpjheHcHEbIU70mZ60MYOLPHRHhQcOP e6KetlhAKmt8pZAEOk/K0v6DDyPs9lGhk4C5KV1U4muPGJ1iyDxr85zRtMqz5fvuDL+dL2uyr 3Kdz4olADTdJhE9/XKTCdekECR0rWARbnO/VvmRQbLXnF9sBkTzxBsIaGEEakhMi31iV4UaAn jTfJFSCtRHsvS4obs/OCDV4EDDOVASb7TEzKs3SrtrmuEt2iuv+hKudSHyFV0pkrpPGE1j1Bn mubunuT 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 12:22:15 -0000 Hi Dave, On Oct 30, 2015, at 13:07 , Dave Taht wrote: > 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. I disagree, based on mere gut feeling and the conviction that = =93trust us we know what is best for you=94 is not a strategy to = success. Let=92s supply a great working even optimal default target and = allow anybody to shoot their own feet if they want to. Our own history = of target in cake does not fill me with confidence that we will get it = right; for example we all seem to agree that target should maximum 5-10% = of interval or the transfer time required for of one full MTU plus = encapsulation packet worth of bytes, but we have not reached consensus = whether the target increase on slow links should also result in an = increases of interval to keep target at X% or not. Exposing target will = allow to remedy this (by recommending users to manually change a = sub-optimal default) with already deployed cakes instead of forcing a = rebuild on our users. Also I think it totally par for the course if tc/cake would = heavily complain about un-reasonable interval target combinations so the = user knows without doubt that are on their own by their own volition. > 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. The >>4 thing is a bit of a puzzle for me, I believe we only = ever calculate target during intiallisation and not repeatedly during = operation so a division would just be as well, heck even a cast to float = an FP-division, truncation of the fractional part and cast back to int = would be in the noise (I am not proposing this and the kernel might not = really want to use the FPU, all I want to illustrate is that I am not = sure whether the shift really buys us that much ;) ). I like your = rationale for the 6ms for cable though, and given the rather approximate = rationale for 5% in the codel RFC I believe that is a good justification = for >>4 ;) How would you test this, by the way (just curious, I have no = cable link otherwise I would volunteer to re-confirm whether >>4 beats = /20). But what if DOCSIS 4.0 changes the temporal grant granularity to = say 1ms? >=20 > 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. I certainly have not, all of this is outside of my (current) = skill set, which might explain my almost stubborn insistence on minor = points=85 Best Regards Sebastian >=20 >=20 > Dave T=E4ht > 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 >=20 >=20 > On Fri, Oct 30, 2015 at 5:13 AM, Sebastian Moeller = wrote: >> Hi Toke, >>=20 >> On Oct 29, 2015, at 16:40 , Toke H=F8iland-J=F8rgensen = wrote: >>=20 >>> 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. >>=20 >> 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 >>=20 >>>=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. >>=20 >> 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 >>>=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. >>=20 >> 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 >>=20 >> Prtesonally I would prefer the second, but I like numbers ;) >>=20 >>>=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. >>=20 >> 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 ;) >>=20 >>=20 >> Bet Regards >> Sebastian >>=20 >>>=20 >>> -Toke >>=20 >> _______________________________________________ >> Cake mailing list >> Cake@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/cake