Re: [Cake] second system syndrome

[Jonathan Morton <chromatix99@gmail.com>]

> On 23 Dec, 2015, at 13:43, Dave Taht <dave.taht@gmail.com> wrote:
> 
> squashing and washing are both well within the realm of ietf best
> practices. It is highly desirable to have this level of simple control
> on cake for inbound - for example, 90+ of all comcast traffic, no
> matter how originally marked, comes in marked as background, and
> should be changed to best effort on the gateway. Doing so with an
> iptables rule is inefficient and it is difficult (along with the rest
> of sqm-scripts) to hook into other people's iptables rules.

My argument is simple: if you care enough about Diffserv to notice Comcast meddling with it, you almost certainly want to do something *much* more sophisticated than just “wash” or “squash”.

The one exception I can think of is where the untrusted DSCP interacts badly with some congested internal-network equipment - such as a long wifi link - that can’t be reconfigured to ignore untrusted DSCPs.  So I can see why you specifically are interested in the “squash" feature, but pretty much nobody else will be.  “Wash” is just plain wrong.

Given that this entire thread is about concern over scope creep, changing the DSCP is my line in the sand.  Doing it properly is out of scope, so doing it *at all* is *also* out of scope.

What “wash” and “squash” have done, though, is to show that changing the DSCP in a qdisc can be done.  Hence, it should be straightforward to implement a qdisc, which can be stacked with Cake or any other Diffserv-aware qdisc, that covers the common use-cases properly and without the major overhead of firewall rules (which, in any case, apply too late to be useful on ingress).  I have some ideas, which I intend to detail separately.

As a compromise, I’ll leave “squash” and “wash” in place (since they’re already there) until a better solution is available.

 - Jonathan Morton