From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 348D221F750 for ; Fri, 30 Oct 2015 05:07:13 -0700 (PDT) Received: by oiad129 with SMTP id d129so57888617oia.0 for ; Fri, 30 Oct 2015 05:07:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=w+Eh3ju4YNK0Qb13KP4qnULpMz6aWtV+IaaYt9/aFjo=; b=T3K408T5ks6sfnNskgAdQc1Cmx9M21DepW4S7E0q5/rTEJU6m+OFm/VvEs+CjWQXwM D2stF+HmtKPICkGf0zDpFgG1rcOa8x4MqSE5iiSVFWaeYZ/AQDs3R2vHiT82YVeMB6IJ TifusMMHqyCR8i3fj6HkNNTo7UE1063uqMiUWZU4vxL8kZXnxjsgFiqD6nfC0uPK63xC Oz+yu4bc4sU95isYtxKpBwA61+XoP/Q+EzMINdc9n4RBKeyHpT8JXVdIVSFw/aSQO4zE TY9zs3lLhn1Ph/i6yKXG7qT+WiPpuQ2cPCwME9DKTXcQ3mexIzb51woJAGOmOp3VVFOn eMtg== MIME-Version: 1.0 X-Received: by 10.202.203.74 with SMTP id b71mr5129731oig.104.1446206832854; Fri, 30 Oct 2015 05:07:12 -0700 (PDT) Received: by 10.202.61.133 with HTTP; Fri, 30 Oct 2015 05:07:12 -0700 (PDT) In-Reply-To: <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> <2E05CB23-D755-414E-86BB-A69C928D321F@gmx.de> Date: Fri, 30 Oct 2015 08:07:12 -0400 Message-ID: From: Dave Taht To: Sebastian Moeller 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: Fri, 30 Oct 2015 12:07:36 -0000 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. 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. 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. Dave T=C3=A4ht 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 On Fri, Oct 30, 2015 at 5:13 AM, Sebastian Moeller wrote: > Hi Toke, > > On Oct 29, 2015, at 16:40 , Toke H=C3=B8iland-J=C3=B8rgensen wrote: > >> Sebastian Moeller writes: >> >>> Hi Toke, >>> >>> On Oct 29, 2015, at 12:02 , Toke H=C3=B8iland-J=C3=B8rgensen wrote: >>> >>>> Sebastian Moeller 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, th= e >>>> road to bloated interfaces is covered in good intentions. Each additio= n >>>> may be worthwhile in itself, but the sum of them becomes a horrible me= ss >>>> 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 use= r >>>> to figure it out. >>> >>> I am all for empowering the users to change the settings (well, th= e 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 s= eem >>> 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 cake= 2 or >>> cookie can have different exposed parameters than cake, no? >> >>> We avoid the =E2=80=9Chorrible mess=E2=80=9D part by basically req= uiring 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. > > 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 u= pon uses and exposes; so with cake being in some sense a successor of fq_co= del, I see no reason why exposing those will cause legacy issues. As alread= y said if we switch away from codel under the hood there is no reason to ke= ep the cake name and the parameters. Limit however absolutely needs to be e= xposed as there is no real way to divine the optimal limit for each deploye= d 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 re= quire to run another application on the router), or to come back to our exa= mple, a user on a high bandwidth satellite link but struck with a puny rout= er might still prefer to sacrifice some good put if that helps avoid un-pla= nned reboots=E2=80=A6 Or put differently limit is a policy parameter and he= nce should be exposed to the user; and in a sense so are is the target to i= nterval ratio, according to the codel RFC this controls the bandwidth sacri= fice and the resulting median queuing delay, which are also policy decision= s the user should be able to control. > Again "should be able to control" is not incompatible with =E2=80= =9Cshould not need to touch as the defaults are sane=E2=80=9D in my view ;) > > >> >> 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 e= xposing these is that it will allows us more leeway in changing the default= s later on (I believe after upstreaming even changing defaults results in d= iscussions whether that does not catch current users by surprise...) > >> >>> The current set of named rtt-target combinations for example seem to >>> gotten it slightly wrong... >> >> Not a big fan of those either. > > To play devil=E2=80=99s advocate, in the ideal case they will mak= e 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 6= 2.5ms > > Prtesonally I would prefer the second, but I like numbers ;) > >> >>> 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. > > I totally buy this argument; all I question is do we really see c= ake switch away from using codel underneath? If not then exposing target an= d interval should do no harm. And limit is something all qdisc should requi= re by law ;) (I believe most actually honor this already). Please note that= I do not propose to expose variables to modify the different diffserv sche= mes, I am totally fine with those being hard coded ;) > > > Bet Regards > Sebastian > >> >> -Toke > > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake