From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 E99863B2A4 for ; Fri, 23 Dec 2016 07:40:09 -0500 (EST) Received: from [172.17.3.76] ([134.76.241.253]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MQRZw-1c8P7o20AG-00TpMV; Fri, 23 Dec 2016 13:40:04 +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: Date: Fri, 23 Dec 2016 13:40:03 +0100 Cc: Stephen Hemminger , cake@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: References: <20161222174349.5bd5dffd@xeon-e3> <9A8ACB3B-8411-414E-B2C3-ABE2C276B351@gmail.com> <606D54F6-59FB-49D6-A969-F26434EF9292@gmx.de> To: Jonathan Morton X-Mailer: Apple Mail (2.3259) X-Provags-ID: V03:K0:3mNgIJwMdrmurFY0ZALhc/CdvhtSPjM+U9fqfMmDEHX8Zb4/cJi dhaLS8hqqwbij934HxzCY9+dbgidAh4OotVkV/JP7LRgofpEALU1J7GNWlvj7LPwpwmsGsU aK3XLxO7p2eKf7JRqDJIs2P8DT2VOHU/TeI1PBSTqfrDd0sG72FQcMdQs0LHmp8o4MYgpLN AVSsMEBfvLwwGDqV+6inw== X-UI-Out-Filterresults: notjunk:1;V01:K0:0GB766Pp+R8=:56nY0RathXtxEZrMXTE1Uh DZ+ip2tndoYXV4OfgiHjRpCaQybJkj3eUyNUjxOSOjjdLtEU8CTN2FT0eCnpW3SF9hb/UlXB/ oSBuKvpr8OlkO9+UtDff1YxNK/w8RSDzfBI3k99mlsQMi80QRUMFl05TudMKFWlY/XJJFV69a BGv1Avzi7BM42xOKWX0zRO1ewIBiJWlaWAzam4w1BWIFnTGINaRGQef0yPym1uy+tcm1gJkRP pOR0HDA3iBdkz7FaBn4uBbNv8B3HPYZAAvMgi+eGwnBNxE1S4oZ0hNHyQRZngZo5YYEvwo2Uy +Ikiuuzs59OBuPkH1bMUc11w7E9LC2iLOY4OE1rydlyX6pYdXoiClkj/4k9tVTEeffac4sMEq Wo7Jgf+aTu2bDS6dE+jzWGoQo8dIcfk/tV1gSF+mcVmvHNlXdOnWcfyXR0z7EL2PzZNCmRjch YxutW2xxVk3Xhza4mPM9ki24V+8XvsPQ8cyP2pUKtHemkeaNMOvfYpC2M/ZLzvaG7WF52mRYY MNohQinauMAHVDGMh74j0CEYIAXsmA2xAiWgxRb84IIcnExBWTEkbZqE011c/jBdjU/ohk9Dl syGpGDdtKN/NVPbceCT0gI1pzxLU1+f9QjKUvT3A8QcUT2KpEK2Zpuc606NNu9NJimmn0Lg/7 N6x2IdlUvx2uNHYuhZPa93PBRCFgNoujhxaqznbc5sO/T1o66Xm//xPJDB286rKVCWGCRUC6F LzRusZi03koSzRITM56HxiSx+sEPKgg3PCOfFywiNw78Mk4oITNR78td+PlZ742zu9+hnhtnA CwCDvkNayRBajOlpN11ZQ9iRKme9KkDwTyNUSmAfaZkXT+ObnoIsrKmjk7irDNdQwc/5erb3J OqGxFTfSKRSO9flqaLp+VnDqqQ5wSk8Xe4b/VTWKbed3k/R+k27cMG4y8/xu7F7l1CXOvdWz7 6nSD9hn1ad+TGNTBm+dYwE+tva9QiIVBulsRVkpF0RlLdFNZW7477UwxiBUusAJc6nF7msZCw O3z1RVliBKDX+Is77S8+3YzEbrsKHJtkOQKZRwB0jHfQEqyA0GPxijwdJ/vuIIUDbw== 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 12:40:10 -0000 Hi Jonathan, > On Dec 23, 2016, at 10:53, Jonathan Morton = wrote: >=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. >>=20 >> ??? This comes close to ignoring reality. The RFCs are less = important than what people actually send down the internet. >=20 > What is actually sent down the Internet right now is mostly = best-effort only - the default CS0 codepoint. My inbound shaper = currently shows 96GB best-effort, 46MB CS1 and 4.3MB =E2=80=9Clow = latency=E2=80=9D. >=20 > This is called the =E2=80=9Cchicken and egg=E2=80=9D problem; = applications mostly ignore Diffserv=E2=80=99s existence because it has = no effect in most environments, and CPE ignores Diffserv=E2=80=99s = existence because little traffic is observed using it. >=20 > To solve the chicken-and-egg problem, you have to break that vicious = cycle. It turns out to be easier to do that on the network side, = creating an environment where DSCPs *do* have effects which applications = might find useful. 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. Your chicken and egg phrasing of the = challenge completely ignores this, and that is what I only half-jokingly = called ignoring reality... >=20 >> coming up with a completely different system (preferable randomized = for each home network) will make gaming the DSCPs much harder >=20 > With all due respect, that is the single most boneheaded idea I=E2=80=99= ve come across on this list. If the effect of applying a given DSCP is = unpredictable, and may even be opposite to the desired behaviour - or, = equivalently, if the correct DSCP to achieve a given behaviour is = unpredictable - then Diffserv will *never* be used by mainstream users = and applications. Exactly, Diffserv will ever only make sense inside a DSCP-domain = and inside one the code point to priority mapping can be completely = arbitrary as it can not be assumed to make sense in other settings. = Anything else is a) open to be gamed by sufficiently motivated = application writers and will b) need to survive the re-mapping ISPs = might/will do during transit. I know there are proposals to split the = 6bit Diffserv field into two sets of 3bits, one for signaling end2end = intend and three for the current domain's re-mapping of that intent (or = lack thereof). But you knew that.=20 Also calling essentially randomization to avoid attacks boneheaded seems = a bit strong, it is not that this idea is without precedence (see KASLR, = even though 6bits are not much to work with). >=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), >>=20 >> 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. >=20 > If an attacker wants to cause side-effects like that, he=E2=80=99ll = always be able to do so - unless he=E2=80=99s filtered at source. As a = more direct counterpoint, if we weren=E2=80=99t using Diffserv at all, = the very same attack would degrade performance for all traffic, not just = the subset with equivalent DSCPs. Well then the damage would be shared instead of allowing an = attacker to selective degrade the higher priority data, but I see your = point, the malicious actor will cause problems diffserv or not and it is = debatable which problem is actually worse. 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. >=20 > Therefore, I have chosen to focus on incentivising legitimate traffic = in appropriate directions. >=20 >>> So, if Cake gets deployed widely, an incentive for applications to = correctly mark their traffic will emerge. >>=20 >> For which value of =E2=80=9Ccorrect=E2=80=9D exactly? >=20 > RFC-compliant, obviously. This is the other half to my "ignoring reality=E2=80=9D claim, = if you put RFC over observable data you are in for interesting = challenges. >=20 > There are a few very well-established DSCPs which mean =E2=80=9Cminimise= latency=E2=80=9D (TOS4, EF) or =E2=80=9Cyield priority=E2=80=9D (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. Or put differently the internet = is no overarching dscp-domain. >=20 >>> But almost no program uses CS1 to label its data as lower priority >=20 > See chicken-and-egg argument above. There are signs that CS1 is in = fact being used in its modern sense; indeed, while downloading the = latest Star Citizen test version the other day, 46MB of data ended up in = CS1. Star Citizen uses libtorrent, as I suspect do several other = prominent games, so adding CS1 support there would probably increase = coverage quite quickly. The fact that torrent applications have not jumped upon the CS1 = marking idea (even though they typically do try to be good = scavengers/netizens), should give us pause to think. IMHO the reason is = that torrents want to be robust against ISP interference and hence using = simple identifiers like using CS1 marking seems a hard sell to the = torrent community. But that basically diminishes the potential = usefulness of the CS1 marking. >=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 >>=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? >=20 > There is a compile-time constant in the code which could, in = principle, be exposed to the kernel configuration system. Increasing = the queue count from 1K to 32K would allow =E2=80=9Cseveral hundred=E2=80=9D= to be replaced with =E2=80=9Cabout ten thousand=E2=80=9D. That=E2=80=99s= still not backbone-grade, but might be useful for a very small ISP to = manage its backhaul, such as an apartment complex FTTP installation or a = village initiative. Ah, this sounds great, if the average flow use will increase in = the future cake can be made to cope better by a simple edit and = recompile. Best Regards Sebastian >=20 > - Jonathan Morton >=20