From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 19CB63CB3B for ; Fri, 23 Dec 2016 03:42:58 -0500 (EST) Received: from [172.17.3.76] ([134.76.241.253]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0M0tr1-1cZGvf3bot-00v9dB; Fri, 23 Dec 2016 09:42:56 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Sebastian Moeller In-Reply-To: <9A8ACB3B-8411-414E-B2C3-ABE2C276B351@gmail.com> Date: Fri, 23 Dec 2016 09:42:55 +0100 Cc: Stephen Hemminger , cake@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: <606D54F6-59FB-49D6-A969-F26434EF9292@gmx.de> References: <20161222174349.5bd5dffd@xeon-e3> <9A8ACB3B-8411-414E-B2C3-ABE2C276B351@gmail.com> To: Jonathan Morton X-Mailer: Apple Mail (2.3259) X-Provags-ID: V03:K0:TNxoMdS/8KT9jnW6oJ1cFZhRfJQUlpSED+SACmF6bcpLai0zEVN Ng1+ehLDC6pCpv3O73iyyVYioSqmyjjYRshIIOQuehdKursxH1ls7LyiUPSEj/vezCXaBdq lzaJiwkrLFNyu8Jh/zOYsEcJnpCfo+ws0UVxA3EcgU3/wy06haM1jzPzOMklwCA2aEuoc2x fBq4JzgyzFdNa0rwuWdLg== X-UI-Out-Filterresults: notjunk:1;V01:K0:9BlV8PrqE14=:w1nfSyIBIcmpty2SmCQPjn APYwoBkuTSqcJxCerePqyHIX/c/7F5Mmspxr7dfZrhmX0rHRxWYyJUBZPCefLNmRtyspIfRQg xcEDovaEEjwU5XrX8M8RHIRlOaCxIqDF+su71gNs6V7CPYCmJkWxc4sADXoSWCFvSTpZm9Ca2 ACGk/YxhABhkW0ZZKOtb+s9caihbX6NqXFs6UcXF0q1PmqJV568UgWzIckFPn9/3DpKThc28I K8p9Q7U78vwpOGbksbKjKOAfFVhJfb/LDyA+fWTMxvbfuzg66MlZJN/bgWEcjxngqgjnVgerR y5LxDN1klUu5zimHhGmQF/eZs3Q6hW06zja+Hz3NBNIIwTirt04vPXcPorQqFWjTGma40nYP+ C9q0f5jkZCF8yXN/0KM21i7jwAKBbCQcrnNEQO/mB1vIRo6P/n1TR2DyatQNzej/2gIXobQNn bbvHT0d+yRLxIatd33KAp2RRwQO7cmkeNtZlDXN9a0BXIxiA7scNjgt7PYagffKpFpr8qumw1 29Dt4Rgl4ZMn5xvFHg15wY19RY5GuWfJrFHoOsBUDdlaig6oUgo9XbeMn67JDZiM7O7ofCHJF Wd1KDnThClgOJoh8GNP1gthTyT7BM3kAkrYLtBRQyJZxT/X8T9Ax1WhtATDO/wm9O7yAY/Ta+ T/uXbX0vO3AFNELn5KXYscYgzm3KCuiViMApHUIYF1ibevc4AfnuChmdC0DGXuLK1/AmkQd+c ESRhEQKH8LxXQ9qnvDK6A07aWiwRk8U/R+n6c7959GiBf1cqrzM4PrypS3L7HjZrZ3pSMUhRY LaL600i Subject: Re: [Cake] upstreaming cake in 2017? X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2016 08:42:59 -0000 Hi Jonathan, > On Dec 23, 2016, at 04:44, Jonathan Morton = wrote: >=20 >=20 >> On 23 Dec, 2016, at 03:43, Stephen Hemminger = wrote: >>=20 >> It would also help to have a description of which use-case cake is = trying to solve: >=20 >> - how much configuration (lots HTB) or zero (fq_codel) >=20 > One of Cake=E2=80=99s 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. >=20 >> - AP, CPE, backbone router, host system? >=20 > 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. >=20 > Cake could also be used in strategic locations in internal (corporate = or ISP) networks, eg. building-to-building or site-to-site links. >=20 > 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. >=20 > Deployment on core backbone networks is not a goal. For that, you = need hardware-accelerated simple AQM, if anything, simply to keep up. >=20 >> Also what assumptions about the network are being made? >=20 > 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=E2=80=99s time). > or that legacy Precedence codes are in use (which is deprecated but = remains plausible) - and both of these additional cases are also = supported. >=20 > Cake does *not* assume that DSCPs are trustworthy. It respects them = as given, but employs straightforward countermeasures against misuse = (eg. higher =E2=80=9Cpriority=E2=80=9D applies only up to some fraction = of capacity), But doesn=E2=80=99t 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. >=20 > So, if Cake gets deployed widely, an incentive for applications to = correctly mark their traffic will emerge. For which value of =E2=80=9Ccorrect=E2=80=9D exactly? >=20 > 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=E2=80=99t). 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... >=20 > If you have complex or unusual Diffserv needs, you can still use Cake = as leaf qdiscs to a classifier, ignoring its internal Diffserv support. >=20 > 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. >=20 > Conversely, Cake=E2=80=99s 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.=20 >=20 > 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. =20 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. >=20 > - Jonathan Morton >=20