Re: [Cake] upstreaming cake in 2017?

[Jonathan Morton <chromatix99@gmail.com>]

> On 23 Dec, 2016, at 14:40, Sebastian Moeller <moeller0@gmx.de> wrote:
> 
> You seem to completely ignore that given DSCP-domains the DSCP markings are not considered to be immutable property of the sender but are used as a scratch space for intermediate transport domains. Any scheme that does not account for that will never reach end2end reliability of DSCP-coded intent. 

And this is why I listed RFC-compliant DSCPs as an assumption about the network, when the question arose.

I happen to believe it’s reasonable to assume that DSCP remapping will *normally* use RFC-allocated DSCPs for their RFC-compliant meanings, and DSCPs in the unallocated and private-use spaces for internal meanings.  That’s sufficient for RFC-compliant Diffserv behaviour to be both useful and expected.

There will be occasional exceptions, but so far those have not showed up to any noticeable degree in my corner of the Internet.

> But I also note that it is generally advised to re-map CS7 on ingress to basically take the remote offenders capability away to affect the network management traffic.

Cake does not assume that it is at the edge of a Diffserv domain, which is where such remapping would be appropriate.  I leave it to firewall rules if required.

> if you put RFC over observable data you are in for interesting challenges.

My observations of reality are mostly consistent with the RFCs.

>> There are a few very well-established DSCPs which mean “minimise latency” (TOS4, EF) or “yield priority” (CS1).  The default configuration recognises those and treats them accordingly.
> 
> Which sounds fine with the caveat that those can not be trusted on ingress without checking them first.

And as I have said several times in this thread alone, Cake does not trust the DSCP field blindly - yet it does not need to “verify” it, either.  It interprets each DSCP as a request for a particular type of service, and each type of service has both advantages and disadvantages relative to other types.

Using the new “diffserv3” mode as an example, there are just three tins.  The default CS0 code, along with almost all the others which might randomly occur, end up in Best Effort, which is tuned for a general mix of traffic with “normal” Codel parameters.

CS1 gets shunted into the Bulk tin, which is guaranteed only 1/16th of the link capacity, and yields any use of the remainder to the other two tins - there is clearly no incentive to use that rather than CS0, except for altruism.

TOS4, VA, EF, CS6 and CS7 all go in the Voice tin, which is tuned for minimising latency - even if there is no competing traffic, bulk TCP flows will tend to get reduced throughput due to the more aggressive Codel parameters.  Priority is substantially raised (by way of a large WRR quantum) over Best Effort - but only as long as tin throughput stays below 1/4 of the link capacity.  Trying to increase bulk throughput by using one of these DSCPs will therefore be counterproductive, while trying to reduce peak and average latency is exactly what it’s for in the first place.

An example of a Diffserv implementation that *did* blindly trust DSCPs would be a strict-priority scheme without any failsafes.  Cake is not one of those.

> Or put differently the internet is no overarching dscp-domain.

No, but in the absence of an explicitly administered alternative, RFC compliance *is* the default and expected mode of the Internet.  If you no longer believe that, then perhaps you should stop trusting your TCP/IP packets entirely.

In any case, if it is necessary to remap DSCPs in any way to bring them into RFC compliance, that is not Cake’s job.  Use firewall rules or a classifier qdisc.

 - Jonathan Morton