[Cake] upstreaming cake in 2017?

[Sebastian Moeller]

Hi Jonathan,

> On Dec 23, 2016, at 15:06, Jonathan Morton <chromatix99 at gmail.com> wrote:
> 
> 
>> On 23 Dec, 2016, at 14:40, Sebastian Moeller <moeller0 at 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.

	One of the use cases for cake that we constantly push is on the WAN interface of a CPE; if you do not consider a personal home net a different DSCP domain than the ISPs access network, I do not know what you would call  a domain boundary. But I guess I presented mu arguments and will stop now.


> 
>> if you put RFC over observable data you are in for interesting challenges.
> 
> My observations of reality are mostly consistent with the RFCs.

	Well, only if you consider it to be RFC conform if an intermediary network re-mapps to e.g. zero (in my case flent RRUL packets are re-mapped to zero for IPv4 but conserve their markings for IPv6, and I believe Dave reported his ISP delivering a considerable portion of CS1 packets, that appeared to have been initiated as !CS1).


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

	But those RFCs seem to state that one can not expect specific mapping on ingress and that one is free to what ever one wants inside a domain. Now an optimistic interpretation is that baring better reasons people will slowly and automatically evolve their mapping schemes to be closer to some RFCs.

> If you no longer believe that, then perhaps you should stop trusting your TCP/IP packets entirely.

	This is not so much e question of my believe system, but the fact that I am not convinced that the data fully supports your view. I will shut up now, and try to get a few packet captures in my network, while definitive it should give me an idea whether my pessimism might unjustified.

> 
> In any case, if it is necessary to remap DSCPs in any way to bring them into RFC compliance,

	Here I disagree, RFC compliance has in my eyes zero importance on re-mapping the only question one needs to answer is whether the re-mapping makes sense inside an DSCP domain.

> that is not Cake’s job.  Use firewall rules or a classifier qdisc.

	Funny you should say that, but I believe on ingress cake on an IFB will run before the firewall (but I might be completely wrong).

Best Regards
	Sebastian

> 
> - Jonathan Morton
>