From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (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 35CAC3B260 for ; Wed, 1 Jun 2016 08:25:55 -0400 (EDT) Received: by mail-oi0-x233.google.com with SMTP id w184so24216998oiw.2 for ; Wed, 01 Jun 2016 05:25:55 -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; bh=XT5UnTRFbT5q4+ncoNhenEEYGT1iuXWyh+bS/tHS354=; b=JhNOrxadr7xOSGOj0kyfLyQcqZO/IJ8zeIOUHpj7wZs24zcgXO7OYoBR7LqitofmRV OPyEDZEJCErRVg8yXXUlsHr92ShoOA/t/f9u3ulN71TrfFEE4lMopOVvf63gH4M+m0Zy 5BliN2Ks2DgtYCm5Ol6WfluxU+VnvQiVU4Nh9+Ramym2KoZc/byeEIUX03OeS9JcTU9f zyTcuPkbs5iYHfa36Fl9hVtK0Z0SKA4cwmntUL3fn1MmJjzyrwM+vdizSS8GQiAKg03M FpizNkNNO0wmpUeJOYCko+VQjkQElYSydsv2ZKRT9/HcrSe9z+XBgx/r0RJPAQwCdxeE QvVQ== 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; bh=XT5UnTRFbT5q4+ncoNhenEEYGT1iuXWyh+bS/tHS354=; b=mqqpAoC+KqGdK5bqZ34MOPR5LNFF8Cgu3oPORU8zWB0VvT0GIssTBU1FtKzv2FLy0Z g2rh6BuNzP0lWAq8No1EtBQJsUnIr68L6MKPtyhJXFBX9fP4vBVP0g+oaXH1oTlkQRRZ M1OIWanGbZEj3lA5s/d5KoHnJ7EoI9nMRe5I6ORwiuD6fO3z7N3TJUlrmekr/dfk73Bl MKRuRqL4nxf/bOu1RaFt8Jc5PSlObifC2ojVzQjIwunX7eumXe+0JNEPb86Fq/YJPC42 P5oztpA1q4caPR7EpLenenAnL8D7XTO1YLMzHBxDwaDwa6zKLgKsx/eV5XGN/WS+Qy25 fQVA== X-Gm-Message-State: ALyK8tIjqCzaJBQiLc/GPNfkg/HZrhzufbTlt7YSHNyxlLyIyAsfrAa1uv50TimfYm1D51VcM1s9tqIj3L8ezQ== MIME-Version: 1.0 X-Received: by 10.202.244.197 with SMTP id s188mr23075044oih.81.1464783954572; Wed, 01 Jun 2016 05:25:54 -0700 (PDT) Received: by 10.157.19.37 with HTTP; Wed, 1 Jun 2016 05:25:54 -0700 (PDT) In-Reply-To: <0026A232-9D17-40FD-83A4-8575C6FFB8C3@gmx.de> 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> Date: Wed, 1 Jun 2016 07:25:54 -0500 Message-ID: From: Benjamin Cronce To: Sebastian Moeller Cc: Kevin Darbyshire-Bryant , =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= , cake@lists.bufferbloat.net Content-Type: multipart/alternative; boundary=001a11c1770649195e0534369783 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 12:25:55 -0000 --001a11c1770649195e0534369783 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jun 1, 2016 at 6:57 AM, Sebastian Moeller wrote: > Hi Kevin > > On June 1, 2016 1:47:42 PM GMT+02:00, Kevin Darbyshire-Bryant < > kevin@darbyshire-bryant.me.uk> wrote: > > > > > >On 01/06/16 12:41, moeller0 wrote: > >> Hi Toke, > >>> I'm guessing this was probably discussed before and I've simply > >>> forgotten; but why does this (rewriting dscp bits) need to be part > >of > >>> the qdisc when you can do it with iptables? > >> > >> Well, cake looks at the DSCP bits already, if it can do the > >re-mapping we potentially would not need to touch iptables at all, > >which cakes goal being simplicity seemed on-focus. But since this > >feature turned out to be contentious, I vote for throwing it out and > >just rely on iptables=E2=80=A6 I believe Jonathan argued that the re-map= ping > >really is an orthogonal issue that does not conceptually belong into a > >qdisc, a valid points as by now everyone agrees=E2=80=A6 > >> > >> Best Regards > >> Sebastian > > > >One silly question from ignorant fool: Can you do the iptables DSCP > >remapping in such a way that the qdisc still sees/prioritize based on > >them but clear/remap on output? > > At least on ingress that is all we can do right now, as the iptables gets > only run after the intermediate functional block device. So we can > explicitly not do what we like, that is to use iptables to re-mapp DSCP > marks to our internal liking and then have these Interpreten to select th= e > correct priority tin... Re-map all to 0 is just a special case of that... > > Best Regards > Sebastian > > > > > >Kevin > > > I'm just going to ask two questions just to reflect on 1) Ideally, regardless of platform, should an AQM or scheduler have the responsibility of changing anything other than ECN? 2) Should you be deciding the responsibility of CAKE based on the implementation of the platform (IP Tables, not IPTables, etc) or implementing the ideal solution? Ideals can be bad if overly zealous, but it's a slippery slope to the anti-ideal every time you give up an ideal for practical reasons. I always ask myself, what is the perfect solution, can it be done, and what are the trade-offs if it cannot be. Single point of responsibility is one of those ideals. --001a11c1770649195e0534369783 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Wed, Jun 1, 2016 at 6:57 AM, Sebastian Moeller <moeller0@gmx.de> wrote:
Hi Kevin

On June 1, 2016 1:47:42 PM GMT+02:00, Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk= > wrote:
>
>
>On 01/06/16 12:41, moeller0 wrote:
>> Hi Toke,
>>> I'm guessing this was probably discussed before and I'= ve simply
>>> forgotten; but why does this (rewriting dscp bits) need to be = part
>of
>>> the qdisc when you can do it with iptables?
>>
>>=C2=A0 =C2=A0 =C2=A0 Well, cake looks at the DSCP bits already, if = it can do the
>re-mapping we potentially would not need to touch iptables at all,
>which cakes goal being simplicity seemed on-focus. But since this
>feature turned out to be contentious, I vote for throwing it out and >just rely on iptables=E2=80=A6 I believe Jonathan argued that the re-ma= pping
>really is an orthogonal issue that does not conceptually belong into a<= br> >qdisc, a valid points as by now everyone agrees=E2=80=A6
>>
>> Best Regards
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Sebastian
>
>One silly question from ignorant fool:=C2=A0 Can you do the iptables DS= CP
>remapping in such a way that the qdisc still sees/prioritize based on >them but clear/remap on output?

At least on ingress that is all we can do right now, as the iptables= gets only run after the intermediate functional block device. So we can ex= plicitly not do what we like, that is to use iptables to re-mapp DSCP marks= to our internal liking and then have these Interpreten to select the corre= ct priority tin... Re-map all to 0 is just a special case of that...

Best Regards
=C2=A0 =C2=A0 =C2=A0 =C2=A0Sebastian


>
>Kevin



<= div>I'm just going to ask two questions just to reflect on
1) Ideally, regardless of platform, should an AQM or scheduler= have the responsibility of changing anything other than ECN?
2) = Should you be deciding the responsibility of CAKE based on the implementati= on of the platform (IP Tables, not IPTables, etc) or implementing the ideal= solution?

Ideals can be bad if overly zealous, bu= t it's a slippery slope to the anti-ideal every time you give up an ide= al for practical reasons. I always ask myself, what is the perfect solution= , can it be done, and what are the trade-offs if it cannot be. Single point= of responsibility is one of those ideals.=C2=A0
--001a11c1770649195e0534369783--