Is there any mileage in considering using Diffserv as the default in both directions when the Besteffort tin is the default behaviour unless traffic is classified? No washing would then allow classified traffic into the other tins is applicable. I don't know if there is any significant overhead to running diffserv rather than besteffort for instances where all traffic is hitting besteffort anyway.
I knew about Comcast (I also saw his post in the past), what I meant is that if Cake is set to a single Tin then it won't matter for Cake what DSCP value is used, and if that DSCP value were to have an impact beyond the router, it would have been problematic for every Comcast customers not using Cake+wash (which would mean 99% of Comcast`s customers).
No, because downstream traffic cannot be relied upon to have proper DSCP flags, making the use of diffserv3 quite unreliable there.
When you refer to 'replacing the qos script with your own' do you mean we would disable Cake in the webui and run something like the present cake-qos, or that we could run something like a 'cake-qos.cfg.add' script to override the web settings?
The whole beauty of cake is that one dose not need to tag traffic to get good QOS as best effort works great. I see no harm in passing the DSCP markings upstream as they might be used and provide QOS on at the upstream routers. How many CPU cycles would be saved by not zeroing that field? I think the value of passing the DSCP markings could be big for some applications and it will make no difference for cake when configured best effort.
You will enable Cake QoS on the webui, but use the qos-start script to either replace or modify /tmp/qos that gets created by the firmware. Think of qos-start as a "postconf" script for QoS.
I don't wash DSCP markings upstream, only downstream because of silly ISPs like Comcast (see @dave14305 's quote of a David Taht Reddit post). Anyone will still be free to change that by modifying or replacing the /tmp/qos script generated by the firmware.
Even if something is designed to be "very simple" (like Cake), there will always be people who will try to overtune things, spending days on tweaking something that might only show a visible improvement in a synthetic test. So, my goal with the implementation is not to try to make the most optimal setup possible, but to go with something that is "good enough" for "the majority". Anyone with a special case or in needs of trying to squeeze every once of performance will have to do so on their own. I largely simply used the layer_cake setup from the SQM scripts, applied some of David Taht's recommendations (as he backed them with actual facts, not just "on paper this will do this and that), and called it good. Most of the work was with everything around that, such as adding the kernel modules, trying to either backport stuff to iproute2-4.3 or upgrading it to 5.11, etc...
