From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-x241.google.com (mail-oi0-x241.google.com [IPv6:2607:f8b0:4003:c06::241]) (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 4DA583B25E for ; Wed, 1 Jun 2016 11:26:19 -0400 (EDT) Received: by mail-oi0-x241.google.com with SMTP id x130so4704323oia.3 for ; Wed, 01 Jun 2016 08:26:19 -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-transfer-encoding; bh=s3HNyq+TnU+u7ph5mYPO/Xb4EpIRP4YoRXlzabn3Kjo=; b=0mzbTOr8EdGJlvrXWWzkJ2qnOrRhnSdlfHCz8UD30QYmSFaW4lrm77gq/dBPg17+3M xpMcAiVbulecpilY1uIQrS/ybZb1LGZO+XJx05yGKop2WNOIWzqGaGvqxedIepagVfEj e6AQknD/nz0mD/eT9YF2EN+WdBMq/n8EwZsa4fIiT3yT+Y1TGtU1BhWt7ZSdGj98IcCV Iqp9ayL0LIVrt+XvrSRR0Lose0/4HS2FqsocRa9HRrRHWCQt1hIYgdDnb6IEOg3sszwQ JXx/UdASxLPzzDsTh76mp+9z08ZavpPOkgQubnSWHkHidUlfpmxBZlmQJvBfuT8+nwqd lxFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=s3HNyq+TnU+u7ph5mYPO/Xb4EpIRP4YoRXlzabn3Kjo=; b=KZjYc4f3RjBwmaHo/FPqH13bDVih2Qcf9Gzf01uuc6xZvJN01e2WlEneBu5Nq2wI3g NkZduxRI5A/kaNzjiQwTbq2FBS6EI27VoFiIwq00pkyefrcJlswwVE9scGICI9uHwvJ2 PQU4I5iT5K0B4hGrCYw83JBQFfgz1HEkTyc9ZeE5ac09MqyVF4kdBbHP1ntu6gaoi6Mp yTJgFEP8zJMex/3go0i6LtWJXHST+IHO4qDu8YFldWo4mt7U111iiouzpf2/7jL4Ope6 aeAW7SJCZr2Qy81C35MSk/SfdAQS8I/PHmq5IYEp9FZM99A8REnTC8SjvlEzBZrOM2bf fNVQ== X-Gm-Message-State: ALyK8tIEHnsHx5O2/WAJT9xl4lsQj0hj+X9NoCMpDYZN7sTSUWdqbPqb3nIYVpoCBIItLPVcZAc7xEHvgty1iA== MIME-Version: 1.0 X-Received: by 10.157.9.226 with SMTP id 31mr484223otz.165.1464794778180; Wed, 01 Jun 2016 08:26:18 -0700 (PDT) Received: by 10.202.229.210 with HTTP; Wed, 1 Jun 2016 08:26:17 -0700 (PDT) In-Reply-To: <54AE2960-D312-479D-8411-96993F087EF7@gmail.com> References: <574EB29B.1000405@darbyshire-bryant.me.uk> <574EB550.5020005@taht.net> <574EB6E2.2020006@darbyshire-bryant.me.uk> <4DDB6EED-A66B-4E34-B233-8DC55F663EBD@gmx.de> <87shwxb1fk.fsf@toke.dk> <574ECB5E.7090605@darbyshire-bryant.me.uk> <0026A232-9D17-40FD-83A4-8575C6FFB8C3@gmx.de> <54AE2960-D312-479D-8411-96993F087EF7@gmail.com> Date: Wed, 1 Jun 2016 08:26:17 -0700 Message-ID: From: Dave Taht To: Jonathan Morton Cc: Benjamin Cronce , cake@lists.bufferbloat.net Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 15:26:19 -0000 My take on it was doing it in iptables was inefficient, error prone, and slow. Interfacing to other people's iptables implementations was and remains especially error prone. My view has always been that iptables should be used mostly for firewall ru= les. I had also had delusions of being able to apply this code and user facing to other OSes like BSD, which lack iptables, per se'. I further had delusions of ultimately replacing tc_mirred with something that could do it as directly part of the ingress qdisc, where I hoped it would speed up by lot by avoiding a copy. as for the dscp re-writing issue, by all means, if you want to rewrite it further than 0, do it with other, custom rules, which eliminates the api issue jonathon mentioned, after rewriting it to 0, and after nat is translated. We need better iptables functionality to do dscp more right in the first place. Am I the only one whose ISP (comcast) remarks all non-best effort traffic as background? On Wed, Jun 1, 2016 at 6:51 AM, Jonathan Morton wro= te: > >> On 1 Jun, 2016, at 15:25, Benjamin Cronce wrote: >> >> 1) Ideally, regardless of platform, should an AQM or scheduler have the = responsibility of changing anything other than ECN? > > This was in part my original objection to having the squash/wash feature = in Cake. > > The other part is that if we are going to rewrite the rest of the TOS byt= e (not just the ECN bits), then we should do it properly, which requires a = rather substantial extension to the configuration API, even if we only try = to cover the most obvious use-cases. > > This would then be a =E2=80=9Csemi proprietary=E2=80=9D DSCP configurator= , acting independently of Cake=E2=80=99s core AQM and shaping functions, wh= ich would have to be duplicated in other AQMs which had similar aims to Cak= e. That=E2=80=99s not a good thing, and feeds back into the first point. > > Hence the correct solution is to put DSCP rewriting elsewhere, making it = reusable. > > In Linux, doing ingress DSCP rewriting before it hits the ingress qdisc p= resently requires the rewriter itself to be a qdisc, but this can have Cake= as a child qdisc. For the simple =E2=80=9Cclearing=E2=80=9D case iptables= can be used instead, as long as Cake is configured to ignore the inbound D= SCP using the =E2=80=9Cbesteffort=E2=80=9D flag. > > - Jonathan Morton > > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake --=20 Dave T=C3=A4ht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org