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

_______________________________________________
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

Reply via email to