Re: [Cake] [lede-project/source] Add support for cake qdisc (#72)

Re: [Cake] [lede-project/source] Add support for cake qdisc (#72)

[Kevin Darbyshire-Bryant]

To try and keep everyone in the loop this has also been sent to the cake 
list.

LR;DR - There's a pull request to the LEDE tree to integrate cake as a 
patch to tc as well as a small, separate core package for 
kmod-sched-cake.  This is a good thing.  The pull request is 
https://github.com/lede-project/source/pull/72

Hannu Nyman is the author of the patch included in the PR - I've 
volunteered to be maintainer until cake really, really, really goes 
upstream.  Lucky me :-)

Hannu's patch included an improvement in column alignment on tc -s qdisc 
show output.  I have updated Dave's tc-adv tree to include this cosmetic 
change 
https://github.com/dtaht/tc-adv/commit/54794117daef5dd16e0ccec4b821f0c67e6b9ede

Jonathan made reference to "a particular misfeature that should be 
deleted".  This mis-feature is DSCP washing.  This has been brought up 
before and to that end I put in some pull requests removing said 
facility to Dave's cake & tc-adv repos.  On that previous occasion it 
was decided it could stay but again it has been mentioned as being 
something undesirable.  I dug around, found my previous 'nosquashwash' 
trees, rebased them and have submitted pull requests again.

https://github.com/dtaht/tc-adv/pull/10
https://github.com/dtaht/sch_cake/pull/25

Maybe it will save a little work.  Or if JM happy I will commit them as 
is.  I personally would like this stumbling block removed for better or 
for worse, let's not stumble over it again :-)

Kevin





On 31/05/16 19:46, Hannu Nyman wrote:
> I have amended the commit (and it is rebased to the current LEDE head)
>
>   * import the cake commit recommended by @chromi
>     <https://github.com/chromi>
>   * define Kevin as the maintainer for cake, thanks @kdarbyshirebryant
>     <https://github.com/kdarbyshirebryant>
>
> @kdarbyshirebryant <https://github.com/kdarbyshirebryant> , regarding
> maintenance:
>
>   * The cake part is easily maintainable, as the Makefile here just
>     defines the commit to be fetched from the original cake repo and
>     sets date as the version.
>   * tc patch may require some manual diff work if the later changes in
>     tc-adv are complex. I actually created my patch a few months ago by
>     making a diff of your tc-adv4.3 branch (that contained tc-adv
>     applied to iproute 4.3) to plain iproute. Then I pruned the
>     non-essential parts (e.g. extra/old cake versions still present in
>     tc-adv, changes to other qdiscs, man pages etc.) from the patch and
>     left only the cake stuff to be compiled. And that was not actually
>     very much. Basically just a new module for tc, small changes to a
>     header file and Makefile. I have since then updated the patch to
>     include the two commits from @chromi <https://github.com/chromi> in
>     April.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <https://github.com/lede-project/source/pull/72#issuecomment-222782884>,
> or mute the thread
> <https://github.com/notifications/unsubscribe/AGMuq2vMBhtdKSJEZTkLXTVLdqomM63hks5qHIINgaJpZM4IqaPW>.
>

Re: [Cake] [lede-project/source] Add support for cake qdisc (#72)

[Dave Täht]

I still think squashing is very important, and essentially required by
several rfcs.


On 6/1/16 3:02 AM, Kevin Darbyshire-Bryant wrote:
> To try and keep everyone in the loop this has also been sent to the cake
> list.
> 
> LR;DR - There's a pull request to the LEDE tree to integrate cake as a
> patch to tc as well as a small, separate core package for
> kmod-sched-cake.  This is a good thing.  The pull request is
> https://github.com/lede-project/source/pull/72
> 
> Hannu Nyman is the author of the patch included in the PR - I've
> volunteered to be maintainer until cake really, really, really goes
> upstream.  Lucky me :-)
> 
> Hannu's patch included an improvement in column alignment on tc -s qdisc
> show output.  I have updated Dave's tc-adv tree to include this cosmetic
> change
> https://github.com/dtaht/tc-adv/commit/54794117daef5dd16e0ccec4b821f0c67e6b9ede
> 
> 
> Jonathan made reference to "a particular misfeature that should be
> deleted".  This mis-feature is DSCP washing.  This has been brought up
> before and to that end I put in some pull requests removing said
> facility to Dave's cake & tc-adv repos.  On that previous occasion it
> was decided it could stay but again it has been mentioned as being
> something undesirable.  I dug around, found my previous 'nosquashwash'
> trees, rebased them and have submitted pull requests again.
> 
> https://github.com/dtaht/tc-adv/pull/10
> https://github.com/dtaht/sch_cake/pull/25
> 
> Maybe it will save a little work.  Or if JM happy I will commit them as
> is.  I personally would like this stumbling block removed for better or
> for worse, let's not stumble over it again :-)
> 
> Kevin
> 
> 
> 
> 
> 
> On 31/05/16 19:46, Hannu Nyman wrote:
>> I have amended the commit (and it is rebased to the current LEDE head)
>>
>>   * import the cake commit recommended by @chromi
>>     <https://github.com/chromi>
>>   * define Kevin as the maintainer for cake, thanks @kdarbyshirebryant
>>     <https://github.com/kdarbyshirebryant>
>>
>> @kdarbyshirebryant <https://github.com/kdarbyshirebryant> , regarding
>> maintenance:
>>
>>   * The cake part is easily maintainable, as the Makefile here just
>>     defines the commit to be fetched from the original cake repo and
>>     sets date as the version.
>>   * tc patch may require some manual diff work if the later changes in
>>     tc-adv are complex. I actually created my patch a few months ago by
>>     making a diff of your tc-adv4.3 branch (that contained tc-adv
>>     applied to iproute 4.3) to plain iproute. Then I pruned the
>>     non-essential parts (e.g. extra/old cake versions still present in
>>     tc-adv, changes to other qdiscs, man pages etc.) from the patch and
>>     left only the cake stuff to be compiled. And that was not actually
>>     very much. Basically just a new module for tc, small changes to a
>>     header file and Makefile. I have since then updated the patch to
>>     include the two commits from @chromi <https://github.com/chromi> in
>>     April.
>>
>> —
>> You are receiving this because you were mentioned.
>> Reply to this email directly, view it on GitHub
>> <https://github.com/lede-project/source/pull/72#issuecomment-222782884>,
>> or mute the thread
>> <https://github.com/notifications/unsubscribe/AGMuq2vMBhtdKSJEZTkLXTVLdqomM63hks5qHIINgaJpZM4IqaPW>.
>>
>>
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] [lede-project/source] Add support for cake qdisc (#72)

[Kevin Darbyshire-Bryant]

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.

Re: [Cake] [lede-project/source] Add support for cake qdisc (#72)

[moeller0]

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

Re: [Cake] [lede-project/source] Add support for cake qdisc (#72)

[Toke Høiland-Jørgensen]

moeller0 <moeller0@gmx.de> writes:

> 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.

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?

-Toke

Re: [Cake] [lede-project/source] Add support for cake qdisc (#72)

[moeller0]

Hi Toke,

> On Jun 1, 2016, at 13:20 , Toke Høiland-Jørgensen <toke@toke.dk> wrote:
> 
> moeller0 <moeller0@gmx.de> writes:
> 
>> 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.
> 
> 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… I believe Jonathan argued that the re-mapping really is an orthogonal issue that does not conceptually belong into a qdisc, a valid points as by now everyone agrees…

Best Regards
        Sebastian

> 
> -Toke

Re: [Cake] [lede-project/source] Add support for cake qdisc (#72)

[Kevin Darbyshire-Bryant]

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… I believe Jonathan argued that the re-mapping really is an orthogonal issue that does not conceptually belong into a qdisc, a valid points as by now everyone agrees…
>
> 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?

Kevin

Re: [Cake] [lede-project/source] Add support for cake qdisc (#72)

[Sebastian Moeller]

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… I believe Jonathan argued that the re-mapping
>really is an orthogonal issue that does not conceptually belong into a
>qdisc, a valid points as by now everyone agrees…
>>
>> 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 the correct priority tin... Re-map all to 0 is just a special case of that...

Best Regards
       Sebastian


>
>Kevin

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [Cake] [lede-project/source] Add support for cake qdisc (#72)

[Benjamin Cronce]

[-- Attachment #1: Type: text/plain, Size: 2312 bytes --]

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?
> >>
> >>      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… I believe Jonathan argued that the re-mapping
> >really is an orthogonal issue that does not conceptually belong into a
> >qdisc, a valid points as by now everyone agrees…
> >>
> >> 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 the
> 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.

[-- Attachment #2: Type: text/html, Size: 3052 bytes --]

Re: [Cake] [lede-project/source] Add support for cake qdisc (#72)

[Kevin Darbyshire-Bryant]

On 01/06/16 13:25, Benjamin Cronce wrote:
>

> 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.


Thank you, that has really helped clarify my thinking. I'm definitely 
happy for it to go. Based on the above it should never have got in!

I believe that Dave's concerns can be addressed by iptables rules (as 
would have to be done with other qdiscs anyway)

Anyone against?

Jonathan, would you like me to merge those pull requests to remove 
'wash' or do you have a better way of implementing?  I'm less worried 
about backwards/forwards compatibility because as as far as I'm 
concerned cake has never been 'released'.  I'm not so much a fan of 
linux's backporting of API changes either!

Kevin

Re: [Cake] [lede-project/source] Add support for cake qdisc (#72)

[Jonathan Morton]

> On 1 Jun, 2016, at 15:25, Benjamin Cronce <bcronce@gmail.com> 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 byte (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 “semi proprietary” DSCP configurator, acting independently of Cake’s core AQM and shaping functions, which would have to be duplicated in other AQMs which had similar aims to Cake.  That’s 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 presently requires the rewriter itself to be a qdisc, but this can have Cake as a child qdisc.  For the simple “clearing” case iptables can be used instead, as long as Cake is configured to ignore the inbound DSCP using the “besteffort” flag.

 - Jonathan Morton

Re: [Cake] [lede-project/source] Add support for cake qdisc (#72)

[moeller0]

Hi Jonathan,

> On Jun 1, 2016, at 15:51 , Jonathan Morton <chromatix99@gmail.com> wrote:
> 
> 
>> On 1 Jun, 2016, at 15:25, Benjamin Cronce <bcronce@gmail.com> 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 byte (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.

	To play devils advocate here, re-mapping to zero might be a special case, but probably the single most important special case, so lack of generality is not the strongest argument against it (as long as the goal is “good enough”). But I already conceded, it is contentious so needs to go, cake is your “baby” so you have the honor to make such calls…

> 
> This would then be a “semi proprietary” DSCP configurator, acting independently of Cake’s core AQM and shaping functions, which would have to be duplicated in other AQMs which had similar aims to Cake.  That’s not a good thing, and feeds back into the first point.

	Not necessarily, one could also argue that the first implementation is free to just “do it” and only after it proofed itself useful one needs to think about generalizing it.

> 
> 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 presently requires the rewriter itself to be a qdisc, but this can have Cake as a child qdisc.  For the simple “clearing” case iptables can be used instead, as long as Cake is configured to ignore the inbound DSCP using the “besteffort” flag.

	I seem to recall that iptables/nftables folks want to be able to “connect” to the ingress ssytem, so maybe that solves the whole issue (short of making the common thing (re-map to zero) simple)

All that said, the decision is made and cake is on its path to upstream somehow, whoooot.

Best Regards
        Sebastian

> 
> - Jonathan Morton
> 

Re: [Cake] [lede-project/source] Add support for cake qdisc (#72)

[David Lang]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1380 bytes --]

On Wed, 1 Jun 2016, moeller0 wrote:

> Hi Jonathan,
>
>> On Jun 1, 2016, at 15:51 , Jonathan Morton <chromatix99@gmail.com> wrote:
>> 
>> 
>>> On 1 Jun, 2016, at 15:25, Benjamin Cronce <bcronce@gmail.com> 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 byte 
>> (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.
>
> 	To play devils advocate here, re-mapping to zero might be a special 
> case, but probably the single most important special case, so lack of 
> generality is not the strongest argument against it (as long as the goal is 
> “good enough”). But I already conceded, it is contentious so needs to go, cake 
> is your “baby” so you have the honor to make such calls…

The remap to 0 is arguably not just the most important special case, but the 
sensible default at any perimeter.

Having to setup iptables rules to do so is going to be significantly slower then 
doing it in Cake.

I think this one special case should probably remain.

David Lang

Re: [Cake] [lede-project/source] Add support for cake qdisc (#72)

[Dave Taht]

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 rules.

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 <chromatix99@gmail.com> wrote:
>
>> On 1 Jun, 2016, at 15:25, Benjamin Cronce <bcronce@gmail.com> 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 byte (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 “semi proprietary” DSCP configurator, acting independently of Cake’s core AQM and shaping functions, which would have to be duplicated in other AQMs which had similar aims to Cake.  That’s 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 presently requires the rewriter itself to be a qdisc, but this can have Cake as a child qdisc.  For the simple “clearing” case iptables can be used instead, as long as Cake is configured to ignore the inbound DSCP using the “besteffort” flag.
>
>  - Jonathan Morton
>
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake



-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org