From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 11DF33B2A4 for ; Fri, 23 Dec 2016 11:24:44 -0500 (EST) Received: from [172.17.3.76] ([134.76.241.253]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0LrNIC-1cheJ50sbU-013AYx; Fri, 23 Dec 2016 17:24:43 +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: <273D5631-610F-4BD7-BBC9-151A1E8F42BD@gmail.com> Date: Fri, 23 Dec 2016 17:24:42 +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> <273D5631-610F-4BD7-BBC9-151A1E8F42BD@gmail.com> To: Jonathan Morton X-Mailer: Apple Mail (2.3259) X-Provags-ID: V03:K0:6fyRwTcB3s11RWO9NualD0FA2EKBjwuONMrpvVA1x/v66bvmOEs 1fIXoP7dghnor7DgV4lu8Cr0qzBESCtixANf7ec8IKOgTrdUNdUHT8Smryb1BAHDITF5Ynh z6oIH57NRtzkPPLgRHsrasVxVP35UPEkn4v/Ey59Q/BPy3j8OUwSrwo2r9JwZv3esRj8Ed2 GKU+yU6uk2D/U4PdruJeg== X-UI-Out-Filterresults: notjunk:1;V01:K0:k0k2rIXx068=:f6jYBAA9GqewcIVM0WI4Sl ysX98lwPyMWXr380CAAANIMHIXFGCPBasDpBCI8n/PeEyJtGkNqPleq0HdyNqXYejZznp731t JYubxJqalAg2U/22pH2e0WANT93Z7zuRT6bXMogdMf6dMWnkwATydfYm5Skm67VKGfBW7+V0M 18RT4pg8xLTsMmHoa1/pP/aykCHSH3TW6sonAH/PXpUEbRzYI03mtbEipvPh+P2Jnn25KAQ2S FwHRsAgeftZ67Xk+p8YdSK/fb2/XkVW93U5d+vENoIntEqVdvL3UUFx/svlc6PIwMiXSCMRtP kBw1JDlkAXxTCrtAPKPmjqHw8dV9mu9Pncu9uN31K7OPQLTEEaHE++IhUPPCk9T4qc9Ftqqdq Mbm6KMYH0XGmaHGE94/DwgVecgkhAQJAK4ur1boueF1+lCbk8zWp8azY+HuydG5SXbyCDHRXO RasBdxsbLJPStG1FzCTdEzB71GfGDb5HVWOCp50276oaSxhRfevKawetx7z+WJqdQ7eYLXrjE uLcwXvVl1Pe1I76hkB9WuFbZxzUwXMmSBoB/mCkPIMDoTpx0tDNQcty+DCUxXex9NO23qmjP0 oP0+djCxpie5sPZMdzeqHHvGicTPOJJCiyaxkOyohja0l88QYpjig26yTf432WnpyEn37eBWj l7QQCruJOuDhWufmHnyify34LYQwpflx5Bslg7HmSHOCpLdYarL0IsGebIMd0NXep5JocwhVo 1TwLhzGi1prr9sWwjOQSv0McJY78W/s5Gs9FotsIcZmFpdV8b2ohvzdhh6o5mbEdX3AMivn3X IEAbeNx 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 16:24:45 -0000 Hi Jonathan, > On Dec 23, 2016, at 15:06, Jonathan Morton = wrote: >=20 >=20 >> 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 >=20 > And this is why I listed RFC-compliant DSCPs as an assumption about = the network, when the question arose. >=20 > 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. >=20 > There will be occasional exceptions, but so far those have not showed = up to any noticeable degree in my corner of the Internet. >=20 >> 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 > 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. One of the use cases for cake that we constantly push is on the = WAN interface of a CPE; if you do not consider a personal home net a = different DSCP domain than the ISPs access network, I do not know what = you would call a domain boundary. But I guess I presented mu arguments = and will stop now. >=20 >> if you put RFC over observable data you are in for interesting = challenges. >=20 > My observations of reality are mostly consistent with the RFCs. Well, only if you consider it to be RFC conform if an = intermediary network re-mapps to e.g. zero (in my case flent RRUL = packets are re-mapped to zero for IPv4 but conserve their markings for = IPv6, and I believe Dave reported his ISP delivering a considerable = portion of CS1 packets, that appeared to have been initiated as !CS1). >=20 >>> There are a few very well-established DSCPs which mean =E2=80=9Cminimi= se 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 >> Or put differently the internet is no overarching dscp-domain. >=20 > No, but in the absence of an explicitly administered alternative, RFC = compliance *is* the default and expected mode of the Internet. =20 But those RFCs seem to state that one can not expect specific = mapping on ingress and that one is free to what ever one wants inside a = domain. Now an optimistic interpretation is that baring better reasons = people will slowly and automatically evolve their mapping schemes to be = closer to some RFCs. > If you no longer believe that, then perhaps you should stop trusting = your TCP/IP packets entirely. This is not so much e question of my believe system, but the = fact that I am not convinced that the data fully supports your view. I = will shut up now, and try to get a few packet captures in my network, = while definitive it should give me an idea whether my pessimism might = unjustified. >=20 > In any case, if it is necessary to remap DSCPs in any way to bring = them into RFC compliance, Here I disagree, RFC compliance has in my eyes zero importance = on re-mapping the only question one needs to answer is whether the = re-mapping makes sense inside an DSCP domain. > that is not Cake=E2=80=99s job. Use firewall rules or a classifier = qdisc. Funny you should say that, but I believe on ingress cake on an = IFB will run before the firewall (but I might be completely wrong). Best Regards Sebastian >=20 > - Jonathan Morton >=20