From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 74DD93CB3B for ; Thu, 22 Dec 2016 20:43:57 -0500 (EST) Received: by mail-pf0-x22d.google.com with SMTP id i88so41856761pfk.2 for ; Thu, 22 Dec 2016 17:43:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=bevjXm2EbmQvkYgKRo+m5+Fe+piBTGcdojp9ZXKTtBk=; b=1loIM94h6AHQvWYlt+u04l130YgjHQI8jcMaPkRsbDZxQIx4RJAu8TNlWqvN6HUPHo MJ6hJdajrzw0rA0aG66hdSmay78BZENyM8Wcwl00qmYGvJNHr22rBWRiLIOChA7/RFxD EWbKCtuduGwqAlt9gvSBlu3yFFlaYYN+vZv2r46NZkt+eTLnGXgyLSh+IjEQ4wo35fRR pgVEFeDpKc/LRl+/ntdzSrRKMBqIWV9zMpDMIpjS1o+n17RuuagAxMtXmb8pQJxaKblI 8xgkkxuATWJEEQAfdg0mPSOu3D2X+bsFMw9G4Ad8PNUcMpieDSkosb3/S18EjM6UrohL as8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=bevjXm2EbmQvkYgKRo+m5+Fe+piBTGcdojp9ZXKTtBk=; b=nZX/BQHn5osVJox5V6wmhNvUw5rDqW3JK+VP4d8gvOEeKyfremXrM7H1d7ugaduLSS OD3T/RYjoK+AJZ19i3VwFUMiyUoRA0ac0XYvHd/rYItDy5z2/h1pDL2jAuq+8trhqRzV NNxaETSusN+EOmiAmY9JJQZEBuHAThvOxyN189UgWh5y55frAMezwXFTkvDLcw/35H9i UE1hCC7lSVdcaOWLuYkEZ77Qyb2Q6Wv58Qa14IQNRSItuQ5Z242epeHS/m8GG6Lmo8fJ vxg/jWMKxDnwauFI9fTtcyzTYhSsgTbtcWDM6xWZtN4RGVN8yi5RSPR4+xBUTCF6jUzh VJcg== X-Gm-Message-State: AIkVDXLLZrGxmkFMFhYqkwr2wqRbcHp07sr6GrQ9szsAVffjb7Njh+iUztpy74RCe9Tu3w== X-Received: by 10.84.241.129 with SMTP id b1mr8555439pll.135.1482457436568; Thu, 22 Dec 2016 17:43:56 -0800 (PST) Received: from xeon-e3 (204-195-18-65.wavecable.com. [204.195.18.65]) by smtp.gmail.com with ESMTPSA id y200sm57464156pfb.16.2016.12.22.17.43.56 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 22 Dec 2016 17:43:56 -0800 (PST) Date: Thu, 22 Dec 2016 17:43:49 -0800 From: Stephen Hemminger To: Sebastian Moeller Cc: Dave =?UTF-8?B?VMOkaHQ=?= , cake@lists.bufferbloat.net Message-ID: <20161222174349.5bd5dffd@xeon-e3> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Cake] upstreaming cake in 2017? X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 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, 23 Dec 2016 01:43:57 -0000 On Thu, 22 Dec 2016 21:02:28 +0100 Sebastian Moeller wrote: > Hi Dave, >=20 > > On Dec 22, 2016, at 20:43, Dave Taht wrote: > >=20 > > I think most of the reasons why cake could not be upstreamed are now > > on their way towards being resolved, and after lede ships, I can't > > think of any left to stop an > > upstreaming push. > >=20 > > Some reasons for not upstreaming were: > >=20 > > * Because the algorithms weren't stable enough > > * Because it wasn't feature complete until last month (denatting, > > triple-isolate, and a 3 tier sqm) > > * Because it had to work on embedded products going back to 3.12 or so > > * Because I was busy with make-wifi-fast - which we got upstream as > > soon as humanly possible. > > * Because it was gated on having the large tester base we have with > > lede (4.4 based) > > * Because it rather abuses the tc statistics tool to generate tons of s= tats > > * Because DSCP markings remain in flux at the ietf =20 >=20 > But does that matter? Is there really a hope that DSCPs will ever work o= utside of a well controlled DS/cP-domain? Because inside one, you can make = any DSCP mean anything you want. Trusting ingress DSCPs to do the right thi= ng and/or be well enough conserved is a lottery ticket. And also trusting t= hat the right applications use the right ietf-compatible markings while no = app tries to abuse those seems optimistic. And finally to end-users the pro= blem is not so much which DSCP to priority bands/tier scheme was used, but = rather how to convince their important applications to actually mark their = packets such. >=20 > > * We ignore the packet priority fields entirely > > * We don't know what diffserv models and ratios truly make sense =20 >=20 > Well, IMHO that is a good indicator that making it configurable in addit= ion to a few well reasoned configuration seems not the worst thing to do, n= o? >=20 > >=20 > > Anyone got more reasons not to upstream? Any more desirable features? > >=20 > > In looking over the sources today I see a couple issues: > >=20 > > * usage of // comments and overlong lines > > * could just use constants for the diffserv lookup tables (I just pushe= d the > > revised gen_cake_const.c file for the sqm mode, but didn't rip out the > > relevant code in sch_cake). I note that several of my boxes have 64 > > hw queues now > > * I would rather like to retire "precedence=E2=80=9D entirely =20 >=20 > Why? At least it is a scheme that can be reasonably well described even = if it rarely will be a good match for what people want. What is does get ri= ght IIRCC is sticking to half of the DSCP bits... >=20 > > * cake cannot shape above 40Gbit (32 bit setting). Someday +40Gbit is p= ossible > > * we could split gso segments at quantum rather than always > > * could use some profiling on x86, arm, and mips arches > > * Need long RTT tests and stuff that abuses cobalt features > > * Are we convinced the atm and overhead compensators are correct? =20 >=20 > The ATM compensation itself is quite nice, the PTM compensation IMHO is = not doing the right thing (less precise and more computationally intensive = than required, even though by probably only little). I still have not becom= e a friend of the keywords (it does not help that at least one of them seem= s not on accordance with the relevant ITU documents). Then again I am sure = the keywords do not need me as a friend. But all of this is optional and he= nce no showstopper for merging (as long as none of them become default opti= ons changing them later seems doable to me). > =20 >=20 > > * ipv6 nat? =20 >=20 > The current believe seems to be that whoever does IPv6 NAT with a /128 a= nd port remapping can keep the pieces. I have no idea how widespread such a= configuration actually is, and adding an option for that after upstreaming= also seems not unreasonable? >=20 > > * ipsec recognition and prioritization? =20 >=20 > Why? >=20 > Best Regards > Sebastian >=20 > P.S.: The only part where I can claim some level of expertise (for a low = value of expertise) is the overhead accounting stuff, so take the rest with= a smile. >=20 > > * I liked deprioritizing ping in sqm-scripts > >=20 > > Hardware mq is bugging me - a single queued version of cake on the > > root qdisc has much lower latency than a bql'd mq with cake on each > > queue and *almost* the same throughput. > >=20 It would also help to have a description of which use-case cake is trying t= o solve: - how much configuration (lots HTB) or zero (fq_codel) - AP, CPE, backbone router, host system? Also what assumptions about the network are being made? Ideally this could end up in both iproute2 and kernel documentation. Don't = worry if it is too much effort right away, LWN might help out.