From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) (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 293183CB35 for ; Mon, 4 Mar 2019 00:37:51 -0500 (EST) Received: by mail-pg1-x534.google.com with SMTP id b2so2223108pgl.9 for ; Sun, 03 Mar 2019 21:37:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mounce.com.au; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=00dPfPaM1R3xSNE0bkelhL3wX+OPR0+1dP51i+KYKZA=; b=XTIn+xMGO0LJYhSXrZ7PiYSMkOHEsEZF3BBQzo1g35v6sIrDcYzd4VLHh8O4C+yHh9 p2+pxIi9i2qgQHsOgT4Qd775mfv4ls2iH8+dzcGlzQDAH7MXaYrvuvu7fsRhYk6K9hUr dhvWEioLVqAee09JqKk4c3Fv+HFEre7wN4aEEFt8k0BaQHFmcT3l7KftHUBtWzNYUfAp nUB9PHKKkEg8515TEjrY93xD8PaSBhKIZThBFTBM/VJwao1ZKEyNMYGXenSf1rT0Hdjs XDGkKrXN33AAAYiGTLFnAHwrFjwcewTkf+Mt5jtv1vKBTQ0TC08PGO02Um6AAlYeFijQ s79w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=00dPfPaM1R3xSNE0bkelhL3wX+OPR0+1dP51i+KYKZA=; b=aFvexOd00BEdenC7cS7yLdnxWvRazI+ArI4WCe5eRVBPMau9Zhi/OO7e1WU+90tPgr Oej8TSHSjqbS/hmcbQm2tNnuIlO11oRRT+FF0+MpgjqZsVWxHJD2+UlUGTUDC/5wl+Fy VhZyKlnKU2Hf/GLt64k/agmK6NxHTde6K815Fekyfkp6rBZjh2h0W9gO2ABZtBfgc0D+ pebBG9p9ZxRFHqjSs1kzTRgkXvtoQWeK8Hm9iB5wh3VaGHczvnYzt8JwQQSo7PKjhMrk nAWUlAESCIkpr56zqeRTkDEisjou/AwXV9WhjHbxnEONd0itJnjMZ4tp5XiCQ32pOW7C Q6VA== X-Gm-Message-State: AHQUAubRRqa3AMqnGHclvCDi3lJFyqeCPUNp15xOvKKIhkjFwldyu1F4 blFMaDXXG+0E5Ppxg3P/DXcu+y8rBTHn6RCa0NU2dg== X-Google-Smtp-Source: AHgI3IbaHmx8sb8IIDyBpxYq3mA9cPG/pN9zf+KlrYSLNRMoWA0C1iLjJlgQrurUVHzAEfZzZ1+iSxODeNf9db4UWHE= X-Received: by 2002:aa7:83ca:: with SMTP id j10mr18374445pfn.50.1551677870203; Sun, 03 Mar 2019 21:37:50 -0800 (PST) MIME-Version: 1.0 References: <1443315187.406067.1551301968084@webmail.strato.de> <000901d4cf15$27748ec0$765dac40$@gmail.com> <67E78212-F68E-4BD1-946D-F1830EEA2968@darbyshire-bryant.me.uk> In-Reply-To: <67E78212-F68E-4BD1-946D-F1830EEA2968@darbyshire-bryant.me.uk> From: Ryan Mounce Date: Mon, 4 Mar 2019 16:07:39 +1030 Message-ID: To: Kevin Darbyshire-Bryant Cc: George Amanakis , "cake@lists.bufferbloat.net" , Felix Resch Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [Cake] Using firewall connmarks as tin selectors 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: Mon, 04 Mar 2019 05:37:51 -0000 On Sun, 3 Mar 2019 at 22:22, Kevin Darbyshire-Bryant wrote: > > Be afraid, be very afraid. > > I=E2=80=99ve woken up with two ideas in my head, one is bad, the other is= very bad. The bad one is already implemented and lurking in the mine bran= ch of my cake git tree: > > The bad idea: > > An extension of the =E2=80=98fwmark=E2=80=99 tin allocation idea is to ge= t cake to automagically update the conntrack mark based on the DSCP tin all= ocation chosen on egress. That way, well behaved applications using DSCP (= e.g. dropbear) get their return path packets similarly classified on ingres= s. Badly behaved applications can have iptables rules put in place to =E2= =80=98manually=E2=80=99 add fwmarks as is already done. > > > The very bad idea: > > And it=E2=80=99s bad =E2=80=98cos it=E2=80=99s sort of incompatible with = the existing fwmark implementation as described above. So an awful lot of = our shenanigans above is due to DSCP not traversing the internet particular= ly well. The solution above abstracts DSCP into =E2=80=99tins=E2=80=99 whi= ch we put into fwmarks. Another approach would be to put the DSCP *into* t= he fwmark. CAKE could (optionally) copy the FWMARK contained DSCP into the= diffserv field onto the actual packets. Voila DSCP traversal across =E2= =80=99tinternet with tin/bandwidth allocation in our local domain preserved= . Ooh now you've got my attention - equal parts horrifying and brilliant. Just making sure I have my head around this, I think it would be perfect for my use case. My ISP requires traffic to be washed on egress, and they wash it on ingress. I set the DSCP in some applications and mangle some others with iptables on the router. Either way, DSCP is present by the time packets reach cake on egress, which dutifully uses DSCP to sort into tins before washing. This works great, albeit with each packet for certain flows being inefficiently mangled. So the first change is that cake will copy the DSCP bits of a packet into the fwmark on egress - if the fwmark hasn't already been set by cake. This allows the impact of my iptables mangle rules to be minimised as only packets without a cake-populated fwmark need their DSCP to be mangled. Cake then uses the fwmark to sort packets into tins, and in my case the DSCP is washed on egress. Then on ingress, cake uses the same fwmark to sort packets into tins. And cake can copy the DSCP bits back from the fwmark to packets on ingress. Magic! The overwriting of the DSCP bits from fwmark could be called 'staining', as opposed to DSCP 'bleaching'. But this doesn't sound very appealing when we're baking delicious CAKE - we're in the kitchen not the laundry! So how about dyeing, or colouring? -Ryan