From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-x242.google.com (mail-lf0-x242.google.com [IPv6:2a00:1450:4010:c07::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id EF87A3CB3B for ; Fri, 23 Dec 2016 04:53:28 -0500 (EST) Received: by mail-lf0-x242.google.com with SMTP id t196so2342089lff.3 for ; Fri, 23 Dec 2016 01:53:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=uKXHy5pwq+/DSHD9P4ZuixxAf3oHYqGePi3d4K1UWL4=; b=CsF56yTiVu7e3P4OtNkjlNgNAvVpilpsr0u8w2Q86jl/oEIL9UwosFZnuPtFC/yjDs 2AMo78vuqnNcGMxzYQkpZRvC7eGrkB6lGS4qJwiYewI0bVGM/0FS6oLkHLIk6djMSKNJ mDccDv6O0D5sg/u8WbZcQnXw7SDcgoxVfZ/DnoMhgyQ+ceQ0BwlNCOoZSDUev80jeHaY UmYQhU1t2pH/SbOxB0fUgFz81yloDFqHeOR24wZH/9uKTcbTyqrHl86achLITKRHSRoc U0+4tS6Jno7j+XmSBeuMVnGbDf8kxtNL0F/stIcz1WAI0NKzdisXZdSz3L75/DpWl1R8 hTpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=uKXHy5pwq+/DSHD9P4ZuixxAf3oHYqGePi3d4K1UWL4=; b=RikNc9ABaHhOHBVSZej140lRrW1MrFXhFQAvlJxAFz1dswtHFlQ/QK63WAk4IPPSfu QnVeje9KlmflMeW1kX9kDuHul+bmCekMtP5s7fmIUBxOHAL0mJSwWpdxKphaZ9xZE1AG jXNzTy5eoHeig8hopZLYxJEWb5EHG+6qrHui8eK64UfyHvTgO32hziINarqCRpg0i0wf N7e9GuLcEk1KQpekHsWFprzSIseoKOQIG0yIv7XofjNRrDO+mWGHhKYG2l62LrdSD328 UFNOaO2UOCAQEBnDw9IemNXzuQ9rQu/fes9hSHid73TV0hr4LrDbJru5ZLA6SkWoQGoi jasg== X-Gm-Message-State: AIkVDXJAlrMgMcJkfyu0wz+B7bJQGUXdeLLlpekfV0frmaVPJrAd0re8Po+eNBXSJ/CCsg== X-Received: by 10.46.7.1 with SMTP id 1mr6535234ljh.76.1482486807409; Fri, 23 Dec 2016 01:53:27 -0800 (PST) Received: from [192.168.100.13] (37-136-37-228.rev.dnainternet.fi. [37.136.37.228]) by smtp.gmail.com with ESMTPSA id s64sm7632715lfs.38.2016.12.23.01.53.26 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 23 Dec 2016 01:53:26 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Jonathan Morton In-Reply-To: <606D54F6-59FB-49D6-A969-F26434EF9292@gmx.de> Date: Fri, 23 Dec 2016 11:53:25 +0200 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: Sebastian Moeller X-Mailer: Apple Mail (2.3124) 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 09:53:29 -0000 >> 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. 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. 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. 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. > coming up with a completely different system (preferable randomized = for each home network) will make gaming the DSCPs much harder With all due respect, that is the single most boneheaded idea I=E2=80=99ve= 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. >> 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. 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. Therefore, I have chosen to focus on incentivising legitimate traffic in = appropriate directions. >> 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? RFC-compliant, obviously. 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. >> But almost no program uses CS1 to label its data as lower priority 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. >> 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? 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. - Jonathan Morton