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
> <[email protected]> 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
> [email protected]
> https://lists.bufferbloat.net/listinfo/cake
_______________________________________________
Cake mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/cake
