> On 23 Dec, 2016, at 03:43, Stephen Hemminger <[email protected]> > 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, 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. No other assumption makes sense, other than that Diffserv should be ignored entirely (which is also RFC-compliant), 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), 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. 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). 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. 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. 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 _______________________________________________ Cake mailing list [email protected] https://lists.bufferbloat.net/listinfo/cake
