From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id F2D183B260 for ; Wed, 1 Jun 2016 06:53:04 -0400 (EDT) Received: from [172.17.3.79] ([134.76.241.253]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MXq3L-1b2IVH2zln-00WkVC; Wed, 01 Jun 2016 12:53:00 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: moeller0 In-Reply-To: <574EB6E2.2020006@darbyshire-bryant.me.uk> Date: Wed, 1 Jun 2016 12:52:59 +0200 Cc: cake@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: <4DDB6EED-A66B-4E34-B233-8DC55F663EBD@gmx.de> References: <574EB29B.1000405@darbyshire-bryant.me.uk> <574EB550.5020005@taht.net> <574EB6E2.2020006@darbyshire-bryant.me.uk> To: Kevin Darbyshire-Bryant X-Mailer: Apple Mail (2.2104) X-Provags-ID: V03:K0:0uTuEvp0/YaNgfbbgCXH3r1Yksc2T6Wgyk2tAYhxi8iO3WzfLyh iC+A9UT/1pmo3oOwhaC43F3CNlx17aXkigWS4VxERyyYHsrT6ZaZMBGPGdKEaSQYRGzNuAp eDf/FUfBU9ptPXds2DOKqqyyQCqBt3XrDYeyYvt+BdFEb+7T4HP88IQ8Vk1MOOma8ZQ52m1 hBvCJyLLl5QkA7Ae0bGgQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:irpgaJ2KsOE=:u070TtzxTTWxZ5iNy6sQlk tiFHWeNwU9AjPwq+tZbsfqFJuoc/Yl6SUdZilWzmNqRMN7LuzA1MbOtPueJ1Vq0qjHzdm11dx YYT8rwwhRClyQYLf/92d5u01ISeQn9BzZ8qxDYeNP0d3KsHCATeEMl0gN0jN2EVjaSlmC8yqF heZUQRXq0sDGWYLa9wY2n7tsiz9y151OBGHhXchprqKo0NE0RueRZMvm3laMJFXuKS1kUAtJQ 7b+2vY+ypM4mlnNFGJt2RsEmhfYKlj+PST5ZFZFzEZIVhNvA2LIvqxQAOQ2qLBxAzC55HvLHk tZvNXD1PCW8hIiMeq9m9zsHjlLWpPizVoAXZShjsRk0NhkYy7rtNXreG8MekMNV3B91LGfpbC qy5ytBJRWuqgYzrZ21deTMJTqd8AnFOg8PAhpYjT6XaIIHGkKyqTRNRrHj7aTAZcJ9HcZlJs/ KYRWLCFvxddj9GX6CR6sPpa1fTM6vMPCM1K8XsXmPUhsG5L8sO9rbeii4SVGPEqTaCws6gpx1 rpUH64wkB+NBPs4AVysny3B+x70tbG7+jCN/Bzi4cR/u61xfluoKodloNkhLF5uIX4haYaC0N O5b4kjXDQhYZBPKLnmRel2BnzuTi7TXivl00F8pH9/H96LmXofBJoVQfdQScXSu1JA1Bmxoeg 3XYz3wFEdRo8gsYKnufCADIQSaVSoaGWdmBWwAfbUzgDqCT7tIrDkV9DRpZn2C7bRahF+0+Jx xabd1YLiaGSI4m1rnxP9NquuDsxfLHvTfKNfA1eTnRYkvKuPMqGAto/23oHzq2zdHAT168usr GZ1lGdI Subject: Re: [Cake] [lede-project/source] Add support for cake qdisc (#72) 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: Wed, 01 Jun 2016 10:53:05 -0000 So, my take on this is that we want to be able to re-map DSCP to zero. = On ingress if we do not trust our upstream to do the right thing on = egress if we do not want to leak internal information to our upstream. = As far as I can tell DSCP is supposed to be domain specific and I = consider a home net equivalent with a domain. This is why I tried to = argue for the existing squash/wash combination. Since Dave had already = implemented the squashing on ingress per iptables in SQM, we will still = be able to offer this functionality in SQM independent on whether cake = offers this natively or not (but note the sqm implementation re-mapped = after using the DSCP marks)*. I tried to divine which mis-feature = Jonathan referred to and remembered his unhappiness with that feature, = and since I really want to see cake go somewhere I am fine with = =E2=80=9Csacrificing=E2=80=9D this feature to make upstreaming more = likely. Sidenote re-mapping DSCP on ingress really is important, as = otherwise upstream can badly affect wifi if WMM is in use. Best Regards Sebastian *: I believe that to become a on-stop qdisc, keeping at least the squash = option in cake seems preferable, but even without this option cake seems = like a worthy addition to lede/openwrt/linux > On Jun 1, 2016, at 12:20 , Kevin Darbyshire-Bryant = wrote: >=20 >=20 >=20 > On 01/06/16 11:13, Dave T=C3=A4ht wrote: >> I still think squashing is very important, and essentially required = by >> several rfcs. >=20 >=20 >=20 >=20 > I'm now wondering if we're falling into a terminology trap. The = original tc/cake implementation of 'squash' was effectively to use = 'besteffort' (ie diffserv1) ie. ignore the DSCP bits *and* to clear the = DSCP bits on outgoing 'wash'. >=20 > I (foolishly?) split out the DSCP washing feature to a separate = controllable flag - wash/nowash* >=20 > Thus it is at present possible to use the DSCP bits for diffserv4/5 = differentiation on ingress to the queue but to clear those DSCP bits for = egress purposes. > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake