From: moeller0 <moeller0@gmx.de>
To: Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk>
Cc: cake@lists.bufferbloat.net
Subject: Re: [Cake] [lede-project/source] Add support for cake qdisc (#72)
Date: Wed, 1 Jun 2016 12:52:59 +0200 [thread overview]
Message-ID: <4DDB6EED-A66B-4E34-B233-8DC55F663EBD@gmx.de> (raw)
In-Reply-To: <574EB6E2.2020006@darbyshire-bryant.me.uk>
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 “sacrificing” 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 <kevin@darbyshire-bryant.me.uk> wrote:
>
>
>
> On 01/06/16 11:13, Dave Täht wrote:
>> I still think squashing is very important, and essentially required by
>> several rfcs.
>
>
>
>
> 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'.
>
> I (foolishly?) split out the DSCP washing feature to a separate controllable flag - wash/nowash*
>
> 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
next prev parent reply other threads:[~2016-06-01 10:53 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <lede-project/source/pull/72@github.com>
[not found] ` <lede-project/source/pull/72/c222782884@github.com>
2016-06-01 10:02 ` Kevin Darbyshire-Bryant
2016-06-01 10:13 ` Dave Täht
2016-06-01 10:20 ` Kevin Darbyshire-Bryant
2016-06-01 10:52 ` moeller0 [this message]
2016-06-01 11:20 ` Toke Høiland-Jørgensen
2016-06-01 11:41 ` moeller0
2016-06-01 11:47 ` Kevin Darbyshire-Bryant
2016-06-01 11:57 ` Sebastian Moeller
2016-06-01 12:25 ` Benjamin Cronce
2016-06-01 13:09 ` Kevin Darbyshire-Bryant
2016-06-01 13:51 ` Jonathan Morton
2016-06-01 15:19 ` moeller0
2016-06-01 20:22 ` David Lang
2016-06-01 15:26 ` Dave Taht
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/cake.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4DDB6EED-A66B-4E34-B233-8DC55F663EBD@gmx.de \
--to=moeller0@gmx.de \
--cc=cake@lists.bufferbloat.net \
--cc=kevin@darbyshire-bryant.me.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox