> On 12 Oct, 2016, at 15:40, ching lu <lschin...@gmail.com> wrote:
> DSCP -> unreliable, easily spoofed by attacker
I’d like to address the “easily spoofed by attacker” point specifically.
Cake’s interpretation of Diffserv is as a three-way tradeoff between throughput
priority, latency priority, and altruism. If you choose a DSCP meaning “low
latency” such as CS6 or EF, Cake gives it higher weight than average, but
*only* if the aggregate bandwidth of supposedly low-latency traffic is below a
reasonable fraction of the link bandwidth. Beyond that point, it gets *lower*
weight than average, but is still able to use spare bandwidth that happens to
There is no way to get “absolute priority”, which this type of attacker would
presumably want, just by setting a particular DSCP. The default “best effort”
DSCP is in fact interpreted as “throughput priority”, which is what most bulk
traffic wants. In this respect, Cake differs from the original IP Precedence
specification (which is long obsolete) and most other naive Diffserv
In short, Cake does not unreasonably *trust* the DSCP field, but instead offers
explicit incentives for traffic to set it correctly. This adheres to the
relevant PHB specifications, which are published as RFCs and thus can be used
as a standard.
The CS1 or “Background” DSCP is the one with an altruistic meaning. It has low
priority whichever side of the bandwidth threshold it lies, so it always mostly
yields to other traffic. Clients are of course permitted to not set it, but
that’s what your firewall rules are for. The Diffserv spec explicitly allows
you to change the DSCP on entry to your own network, which is what I suggested
in my first reply.
Setting the DSCP with iptables rules should work just as well and in the same
way as using the “firewall mark” functionality as you already do. Set it up
that way in the first instance, directly replacing each HTB+fq_codel
combination with a Cake instance, and see how it works.
- Jonathan Morton
Cake mailing list