[Cake] upstreaming cake in 2017?

[Sebastian Moeller]

Hi Jonathan,


> On Dec 23, 2016, at 04:44, Jonathan Morton <chromatix99 at gmail.com> wrote:
> 
> 
>> On 23 Dec, 2016, at 03:43, Stephen Hemminger <stephen at networkplumber.org> wrote:
>> 
>> It would also help to have a description of which use-case cake is trying to solve:
> 
>> - how much configuration (lots HTB) or zero (fq_codel)
> 
> One of Cake’s central goals is that configuration should be straightforward for non-experts.  Some flexibility is sacrificed as a result,

	This does not compute, offering simple configuration options is not at odds with also exposing more detailed configuration methods. The best thing for novices is arguable picking sane defaults...

> but many common use-cases are covered with very concise configuration.  That is why there are so many keywords.
> 
>> - AP, CPE, backbone router, host system?
> 
> The principal use-case is for either end of last-mile links, ie. CPE and head-end equipment - though actual deployment in the latter is much less likely than in the former, it remains a goal worth aspiring to.  This is very often a bottleneck link for consumers and businesses alike.
> 
> Cake could also be used in strategic locations in internal (corporate or ISP) networks, eg. building-to-building or site-to-site links.
> 
> For APs, the make-wifi-fast stuff is a better choice, because it adapts natively to the wifi environment.  Cake could gainfully be used on the wired LAN side of an AP, if inbound wifi traffic can saturate the wired link.
> 
> Deployment on core backbone networks is not a goal.  For that, you need hardware-accelerated simple AQM, if anything, simply to keep up.
> 
>> Also what assumptions about the network are being made?
> 
> As far as Diffserv is concerned, I explicitly assume that the standard RFC-defined DSCPs and PHBs are in use, which obviates any concerns about Diffserv policy boundaries.

	??? This comes close to ignoring reality. The RFCs are less important than what people actually send down the internet. I know I keep harping on this, but to help non-experts it is better to deal with the state of DSCP on the internet as it is right now as compared to how it should be.


> No other assumption makes sense, other than that Diffserv should be ignored entirely (which is also RFC-compliant),

	I beg to differ, as I tried to argue before, coming up with a completely different system (preferable randomized for each home network) will make gaming the DSCPs much harder and not matter which DSCP-svheme is selected, marking in the home network is the biggest stumbling block to experts and non experts alike (judged from trying to support users in the openwrt forum, admittedly a biased sample). Given that specific marking will be required to teach applications to use the wanted DSCPs (I assume OS support to override the application choice of DSCP as the only real option for forward progress, waiting for all networked applications to expose configurable DSCP options makes waiting for Godot a better wast of one’s time).

> or that legacy Precedence codes are in use (which is deprecated but remains plausible) - and both of these additional cases are also supported.
> 
> Cake does *not* assume that DSCPs are trustworthy.  It respects them as given, but employs straightforward countermeasures against misuse (eg. higher “priority” applies only up to some fraction of capacity),

	But doesn’t that automatically mean that an attacker can degrade performance of a well configured high priority tier (with appropriate access control) by overloading that band, which will affect the priority of the whole band, no? That might not be the worst alternative, but it certainly is not side-effect free.


> and incentives for correct use (eg. latency-sensitive tins get more aggressive AQM).  This improves deployability, and thus solves one half of the classic chicken-and-egg deployment problem.
> 
> So, if Cake gets deployed widely, an incentive for applications to correctly mark their traffic will emerge.

	For which value of “correct” exactly?

> 
> Incidentally, the biggest arguments against Precedence are: that it has no class of *lower* priority than the default (which is useful for swarm traffic), and that it was intended for use with strict priority, which only makes sense in a trusted network (which the Internet isn’t).

	But almost no program uses CS1 to label its data as lower priority, and that includes torrent style applications and microsoft distributed update. Which brings us back to the DSCP re-mapping problems that makes DSCP almost useless for non-experts. I would claim that instead of making a special bin for background, use CS0 for that and move everything more important to a higher values DSCP. This has the advantage that it will degrade to the status quo...

> 
> If you have complex or unusual Diffserv needs, you can still use Cake as leaf qdiscs to a classifier, ignoring its internal Diffserv support.
> 
> Cake's shaper assumes that the link has consistent throughput.  This assumption tends to break down on wireless links; you have to set the shaped bandwidth conservatively and still accept some occasional reversion to device buffering.  BQL helps a lot, but implementing it for certain types of device is very hard.
> 
> Conversely, Cake’s shaper carefully tries *not* to rely on downstream devices having large buffers of their own, unlike token-bucket shapers.  Indeed, avoiding this assumption improves latency performance at a given throughput and vice versa.

	Another noteworthy difference between cake and token bucket system is that under CPU starvation cake will try to honor the configured bandwidth at the cost of a little increasing latency while token bucket shapers (with small/no configured bursting) will sacrifice bandwidth. 

> 
> Cake also assumes in general that the number of flows on the link at any given instant is not too large - a few hundred is acceptable.  

	I assume there is a build time parameter that will cater to a specific set of flows, would recompiling with a higher value for that constant allow to taylor cake for environments with a larger number of concurrent flows?

Best Regards
	Sebastian


> Behaviour should degrade fairly gracefully once flow-hash collisions can no longer be avoided, and will self-recover to peak performance after anomalous load spikes.  This assumption is however likely to break down on backbones and major backhaul networks.  Cake does support treating entire IP addresses as single flows, which may extend its applicability.
> 
> - Jonathan Morton
>