From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-x241.google.com (mail-lf0-x241.google.com [IPv6:2a00:1450:4010:c07::241]) (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 3A8193B2A4 for ; Fri, 23 Dec 2016 09:06:15 -0500 (EST) Received: by mail-lf0-x241.google.com with SMTP id y21so19661502lfa.0 for ; Fri, 23 Dec 2016 06:06:15 -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=MctbyYpraBhzC4V2kfO8q4jKWnRayZzQ7+kQzpB0Kd4=; b=DLZV/ltiIG1uDWkHD1Q4Do5j7h+b/nuXYsAX86M9eH+BaweyoW0NzW26mDFfryhf3D M8Rpz+R1yg8f6j6xxHcXmJB+3hwzIPVOyunUKdUQOiaeVVkDxrGmvBnuLTJbU1qfT7EC VkjNrebkLcGAAd2lRvSzHpHV5nC5h6P/mu3oOKz9Go17M4WiLgOt6j2R5o5bEPIR4i+2 8csQCtlSbFxqg8Oq8YiyE2cNhaHNZG7t/q7EVbR8BP0nlYbrZAWAN15AxPYuJuq7YmJ7 cdLU/UPQ4SxQDa3KrP7u7db2HQajQV9NkCw9ErDeeb4E13rsY0+6IBj98DztZxOslkij lOSA== 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=MctbyYpraBhzC4V2kfO8q4jKWnRayZzQ7+kQzpB0Kd4=; b=czMUldEGLNZkcXwzWUjbXdfidJTALdOKuOmbTN/TaXKaBp31RW5kLt86RNUdo4blIS 1qOnlZUZBP4KyyfSWcUbn4rmKz/StXLbh1V1LlfSjRMWQq3cAoshUZ3YSB8/klze248B 6mDuGD7wf5FH1LC+y1tSqLYzIK50CBG0Wlp+wQUak5GaNKrXJhUBEkYSdi4Vy7DO2gmY ucye0HUt4Y6bkw1o/DeTLlPrXcYOwKjU9bLDtgMoV5Yv0vqTEBXJEoDbQQGdy7I9vQ7q O2uZnwXc3H2vvSlnFHjxaNjFmJ8Pz6fwHu8CPREmZhIPk2hkv2axCd1JxhgZvoN/2GPQ KvCg== X-Gm-Message-State: AIkVDXIo7BCp1C115CwGR/KqAnyubZB45tnHpZ6tXi+2kJYQ8+qm45Kn2J3GWlmnozvxYQ== X-Received: by 10.46.13.9 with SMTP id 9mr6931005ljn.37.1482501973926; Fri, 23 Dec 2016 06:06:13 -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 h30sm7773280lji.28.2016.12.23.06.06.12 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 23 Dec 2016 06:06:13 -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: Date: Fri, 23 Dec 2016 16:06:10 +0200 Cc: Stephen Hemminger , cake@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: <273D5631-610F-4BD7-BBC9-151A1E8F42BD@gmail.com> 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 14:06:15 -0000 > On 23 Dec, 2016, at 14:40, Sebastian Moeller wrote: >=20 > 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.=20 And this is why I listed RFC-compliant DSCPs as an assumption about the = network, when the question arose. I happen to believe it=E2=80=99s reasonable to assume that DSCP = remapping will *normally* use RFC-allocated DSCPs for their = RFC-compliant meanings, and DSCPs in the unallocated and private-use = spaces for internal meanings. That=E2=80=99s sufficient for = RFC-compliant Diffserv behaviour to be both useful and expected. There will be occasional exceptions, but so far those have not showed up = to any noticeable degree in my corner of the Internet. > 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. Cake does not assume that it is at the edge of a Diffserv domain, which = is where such remapping would be appropriate. I leave it to firewall = rules if required. > if you put RFC over observable data you are in for interesting = challenges. My observations of reality are mostly consistent with the RFCs. >> There are a few very well-established DSCPs which mean =E2=80=9Cminimis= e latency=E2=80=9D (TOS4, EF) or =E2=80=9Cyield priority=E2=80=9D (CS1). = The default configuration recognises those and treats them accordingly. >=20 > Which sounds fine with the caveat that those can not be trusted on = ingress without checking them first. And as I have said several times in this thread alone, Cake does not = trust the DSCP field blindly - yet it does not need to =E2=80=9Cverify=E2=80= =9D it, either. It interprets each DSCP as a request for a particular = type of service, and each type of service has both advantages and = disadvantages relative to other types. Using the new =E2=80=9Cdiffserv3=E2=80=9D mode as an example, there are = just three tins. The default CS0 code, along with almost all the others = which might randomly occur, end up in Best Effort, which is tuned for a = general mix of traffic with =E2=80=9Cnormal=E2=80=9D Codel parameters. CS1 gets shunted into the Bulk tin, which is guaranteed only 1/16th of = the link capacity, and yields any use of the remainder to the other two = tins - there is clearly no incentive to use that rather than CS0, except = for altruism. TOS4, VA, EF, CS6 and CS7 all go in the Voice tin, which is tuned for = minimising latency - even if there is no competing traffic, bulk TCP = flows will tend to get reduced throughput due to the more aggressive = Codel parameters. Priority is substantially raised (by way of a large = WRR quantum) over Best Effort - but only as long as tin throughput stays = below 1/4 of the link capacity. Trying to increase bulk throughput by = using one of these DSCPs will therefore be counterproductive, while = trying to reduce peak and average latency is exactly what it=E2=80=99s = for in the first place. An example of a Diffserv implementation that *did* blindly trust DSCPs = would be a strict-priority scheme without any failsafes. Cake is not = one of those. > Or put differently the internet is no overarching dscp-domain. No, but in the absence of an explicitly administered alternative, RFC = compliance *is* the default and expected mode of the Internet. If you = no longer believe that, then perhaps you should stop trusting your = TCP/IP packets entirely. In any case, if it is necessary to remap DSCPs in any way to bring them = into RFC compliance, that is not Cake=E2=80=99s job. Use firewall rules = or a classifier qdisc. - Jonathan Morton