Re: [Cake] second system syndrome

[Dave Taht <dave.taht@gmail.com>]

On Wed, Dec 23, 2015 at 1:27 PM, Jonathan Morton <chromatix99@gmail.com> wrote:
>
>> 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”.

Preserving nearly all traffic as mis-marked as background does bad
things to 802.11e.

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

Great. Let's move on.

Are you actually testing your codel changes at longer RTTs?

>  - Jonathan Morton
>