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 ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id DD0B93CB35 for ; Wed, 20 Mar 2019 05:54:42 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1553075679; bh=vHL2A+glKid1roqfI1gkYOIuJSJypvOWsDmunpIPFKY=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=QWf8ZI9c1SM9KK4vungumgSl8WnmnlouR2gyNSQabm1zRDDjjItaItniO6X+Gd+uC F/EQwwU/YyxpqDqPrW0tbl7esSzHG2l/2/idbV6zClx8P5GupuS0JWyXdRDEcD/Tn5 jje2GpImpYIlT0bHZKL2Dch2yDm1451TwQpAeXAY= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [172.16.12.10] ([134.76.241.253]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LhkiL-1gcD7v49FB-00mwLJ; Wed, 20 Mar 2019 10:54:39 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Sebastian Moeller In-Reply-To: <7331132F-F80A-4903-8CD0-48946CFE38FD@darbyshire-bryant.me.uk> Date: Wed, 20 Mar 2019 10:54:37 +0100 Cc: "cake@lists.bufferbloat.net" , Ryan Mounce Content-Transfer-Encoding: quoted-printable Message-Id: <263A35BC-A25C-4CC0-9E75-99A7FAF33D36@gmx.de> References: <7E711BD9-DE6A-4385-8A55-401812D998E8@gmx.de> <7331132F-F80A-4903-8CD0-48946CFE38FD@darbyshire-bryant.me.uk> To: Kevin Darbyshire-Bryant X-Mailer: Apple Mail (2.3445.9.1) X-Provags-ID: V03:K1:RyHj8SxkG9mOxazZru/2tgldLhtHkoXdK1cIDqhw5vBTL3MpAxw K5+QiyROqxM+UMIj72tn2nsNM+1MmlFFICO0I7/D/yjGxq6ILiWrv2TbZ5DldO5QbgriVq4 9jrPb8MGufcYbAoygoGnDl4PJ3vHae9uZhBHCOZvKaepoXDOt2bHy7y8YxusdLmVQH9e5XA CubotXUc2ou5qKyDAp2/A== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:LC/K39GAU28=:uVYcGTwrB56BXnZQOU4/ee W/0Wx0v6t2Ve6MqI0NYsmQy3it/9D2rS29v7fKezeU2EhDywuQSH50IB2DnBsqVSz8jjN6yOC E1M3K9y8d7tyWUg9LuwlEyCIvcwi4KgCY6FolrIzbYtE9KNIL9gp6R1q593eWRe3jYvv30d94 HPZHtGL+Nwzmcn52/pJ4c6vCTRgLky9VfeFGObPd8Kp4wQPW95gTtCNk3wi8n9YogZD2Ql5Z5 atHs16m4WbZBUeOiblyRksFq/oRwvzDaG3xxJGbsNwhZwNDq5BzFrE5Qw6CxZ/lCR5dAw2dja uoQAMHmDpZjO9uoAu2yhKX2dp+AVgBUEhCctsvaPczVGWU3CpawcfYMDW373TQmoOAuYwckjF f6y6mN82ertVcCJd1+1PP2mrWVmHgS8jh5oQK7EDTANz/+cnufgvyRCLHPTn7g/i/I7vGtPhl nMKjkH8CJoGyNKa6Del2eXJNUtC8IXp7/Oc6dc4d9vv4q+O+GETlC8W3d5jKd7apXwEQK1RTg tnKoKr3+czGtxQZ6vUq9y6bS6oJc4O7642ZbxSTyW15vPpFOhwszA4O4S5j/iWV8IQ8y32ihb zAk+yekuuTU4jNvr3JkG10EqESLNeGWLDyLZ3llPYc0gGSDL7rzvF8/pQToTuFAzzhi6nZC/0 lrkIClgfWEda75rx9Eacr7eqirq/OMCd+cIACRdbXAnBkyxWJgEUPNDjptx0LC3Wcp+jvj+u6 a75VuIWiGpNF9EEF+7Zfl7cwBfA6Gb++wXjDGHXM5pV9qnwkR2txgLPlgSOTW/nhDKFLkRzw/ 6sf1sEWuGb0I5PoLAXbEYMnas5ReORGh6rCMhqy5QYi0zmSLZAp5cDwd8DY6LQQgFbYQVCe9l wBnHFOxdaqrHE/lhICH7615J3N65URvsGcZLGxOc89AXAOnZDaantGehfsqCuwfXmvTB/T8Ll OjBl6aYNFQQ== Subject: Re: [Cake] act_conndscp 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: Wed, 20 Mar 2019 09:54:43 -0000 Hi Kevin, thanks for the information! > On Mar 20, 2019, at 10:01, Kevin Darbyshire-Bryant = wrote: >=20 >=20 >=20 >> On 20 Mar 2019, at 08:38, Sebastian Moeller wrote: >>=20 >> Hi Kevin, >>=20 >> Impressive! I had a look at your_layer_cake.qos, and with half the = brain at my disposal currently, I am confused. I had thought the idea is = to set dscp marks on internal hosts or the LAN interface ofva router and = copy those to incoming packets of the same flow, but you seem to set = dscps in ingress. What am missing? >> I ask because I fully bought your cool-aid ;) I want a "mode" for sqm = scripts where easy to set and control egress dscp from internal hosts is = also used for ingress packets of the same flows. I also bought your = argument to preferably only do that once per flow hook line and sinker. >>=20 >> AFAICT this is one feature that would solve a lot of issues regarding = dscps in home networks. Especially in the light of how easy it turned = out to dscp mark packets on windows10, and a lot of the potential dscp = users come from the gaming crowd and need something that works on = Windows. Sidenote, I really like how easy win10 makes it to dscp marks = all egress packets of a given binary, I wish I knew a similarly = straightforward way to do this in Linux and macosx.... >>=20 >> Thanks for this cool feature=E2=80=A6. >=20 > Ha, ok, probably not helped by my commit message having get & set = swapped with regards to the typical usage comments. I=E2=80=99ll try to = go through it in context of my layer cake script. >=20 >=20 > Egress is packet leaving router on wan interface to =E2=80=98Internet=E2= =80=99 > Ingress is packet arriving at router on wan interface from = =E2=80=98Internet=E2=80=99 >=20 > Egress packet goes through iptables mangle table, postrouting. It = doesn=E2=80=99t have =E2=80=99statemask=E2=80=99 bit set so is sent to = the DSCP mangling rule where it may have had the DSCP changed..it = doesn=E2=80=99t matter. Then it will hit conndscp running in =E2=80=98bot= h=E2=80=99 mode. Internally conndscp will go through the =E2=80=99set=E2=80= =99 check first, where it will do nothing because the =E2=80=99statemask=E2= =80=99 bit is unset. Then it will go through the =E2=80=98get=E2=80=99 = check, which it will go through, storing the DSCP into the mark and = setting the =E2=80=99statemask=E2=80=99 bit. This is then passed to = cake as before which uses the DSCP to do tin selection. >=20 > The =E2=80=98reply=E2=80=99 packet will come in on the ingress path. = There it will hit conndscp which will find the conntrack entry and hence = the mark. Conndscp is in =E2=80=99set=E2=80=99 mode, so it will look at = the =E2=80=99statemask=E2=80=99 bit which is set and restore the mark = stored DSCP into the diffserv field on the packet. The packet is passed = on to the cake which uses the now restored DSCP to do tin selection. >=20 > Subsequent egress packets will take this path: It goes through = iptables mangle table, postrouting but this time the conntrack mark has = the =E2=80=99statemask=E2=80=99 bit set, so it is NOT sent to the DSCP = mangling rules. Then it will hit conndscp running in =E2=80=98both=E2=80=99= mode. As before internally it look at the =E2=80=99set=E2=80=99 code = first and because the =E2=80=99statemask=E2=80=99 bit is now set, it = will restore the DSCP contained in the mark to the egress packet. The = get action won=E2=80=99t run because the statemask bit is set. The = packet is passed on to cake which will use the (restored) DSCP to do tin = selection. Ah, but why is that necessary, why not simply keep the DSCP on = the packet as is? Do you want to make sure that packet-captures on wan = will show the effective DSCP in case that differs from the application = set DSCP? >=20 > The ingress path is exactly the same as before. >=20 > I suspect the subtlety is the =E2=80=98both=E2=80=99 action and its = internal order of set -> get which allows the =E2=80=98one off=E2=80=99/=E2= =80=99set forget=E2=80=99 type operation. Much simpler, was/am puzzeled about lines like: iptables -t mangle -A QOS_MARK_${IFACE} -p tcp -s 192.168.219.5 -m = comment --comment "Skybox DSCP CS1 Bulk" -j DSCP --set-dscp-class CS1 in the ingress section. with -s (source?) 192.168.219.5 this looks like = it is processed post-cake (due to ifb preceding iptables), so the packet = looks like it already is in the internal network, as if you would = override the DSCP mark just set by conndscp. That surely seems like a = wrng interpretation, so I would appreciate if you could walk me through = the subtleties here. Thank you very much in advance! Or am I just daft = and this truly is intended to mark outgoing packets and simply kives = inside the ingress() function because it does not really amtter as long = as both shapers are set to rates >0? >=20 > Does that help? Yes, just not all the way, as I said half a brain ATM (aka a = cold). Best Regards Sebastian >=20 >=20 > Cheers, >=20 > Kevin D-B >=20 > gpg: 012C ACB2 28C6 C53E 9775 9123 B3A2 389B 9DE2 334A