From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [IPv6:2607:f8b0:4864:20::62d]) (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 6E8833B29E for ; Wed, 6 Feb 2019 11:19:26 -0500 (EST) Received: by mail-pl1-x62d.google.com with SMTP id e5so3301357plb.5 for ; Wed, 06 Feb 2019 08:19:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:subject:message-id:in-reply-to:references:mime-version :content-transfer-encoding; bh=Bjsu3I6syrmNBVs6NN4shFWMPPQvgL1MOBxZYhSghF8=; b=CSkhbw/PhSjgjsPooduyedb8GTbBeLAks5FsSgLwcMs/LYC1y3Xx+goPP1QJf8rDqV x+R4LK33goJwr4LHeKL2qBnMSO4ALLoiNZp88qYE/tVIFd2f237EEURKx8qXXI5arDVV ESsjIWTJasGYylCgNReKGzT+Oxloa6z08PoT0N7sK0VsrV8GFaEbGQqCPWyT8sT++kF6 Emah1ijsbuhImIxx6bTYUe5Xjwwmk0m2rjwurjwsg9OFrzeEBEiWvXwdaEcl6k9EIYXL TNSUVTL7pN2WSmq76RAe/5IQ1J+Kh3tAzJ3n62BNdyMpWhs6EbBrfqFdi7PZASaHa1az 6/YQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=Bjsu3I6syrmNBVs6NN4shFWMPPQvgL1MOBxZYhSghF8=; b=DpxqwZDtbhiFUsPhTmi6gh93WDLiqDKglACaFU4eXr0xYZ3R0msjiCjv7xEa4Br6xs xy83vZDykhS8Mim4MUx46liI3lM4kC3VsPa2UcIYzooOAWqm9cfHCi/sShEHk/Q+VuxD hQfbioElQcGBZIwSDqLcfDfztFHAhZM1ZIiRPCfM86cCMvZoVYpIn6guAwJRJKXWUlp7 ND1UkNsfsOSI9gub3/ptavNO900koloK9h7oQMSPL67FUdRsmZ5s0TVIIhRCcdR6+Mz7 Nv+XL38M7da+uVm5YvQb95h6DlNesPxKMd2iSXLiCbrvykQmcfXHaw0RuYkH5L/wrQR6 PagA== X-Gm-Message-State: AHQUAuaT+PFMX/eP/EQGBQ1zOrWkiw+mPfTmSxuAB50EN2kUk7hNK6nZ WQyCt9ktwmT0gAR494ywYpffdWr67fE= X-Google-Smtp-Source: AHgI3IaJeNCVKi/Kh4+COA+OCoAj98kcFJ3SSdHMieu6AhgqLOUjGb6ebjpEftq64jj7tmLu9Ph8hA== X-Received: by 2002:a17:902:b40d:: with SMTP id x13mr11552430plr.237.1549469965162; Wed, 06 Feb 2019 08:19:25 -0800 (PST) Received: from hermes.lan (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id z10sm8859168pfg.120.2019.02.06.08.19.24 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 06 Feb 2019 08:19:25 -0800 (PST) Date: Wed, 6 Feb 2019 08:19:22 -0800 From: Stephen Hemminger To: cake@lists.bufferbloat.net Message-ID: <20190206081922.56bd9c42@hermes.lan> In-Reply-To: <65D66C9D-6C65-4307-87AE-35DC93EC5AE1@darbyshire-bryant.me.uk> References: <10501006-3062-47C2-BA2B-4D73155069C1@darbyshire-bryant.me.uk> <2ffe2d11-ed65-6dde-881f-997afa3d8485@sager.me.uk> <65D66C9D-6C65-4307-87AE-35DC93EC5AE1@darbyshire-bryant.me.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Cake] Ingress classification 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, 06 Feb 2019 16:19:26 -0000 On Wed, 6 Feb 2019 12:52:22 +0000 Kevin Darbyshire-Bryant wrote: > > On 5 Feb 2019, at 13:38, John Sager wrote: > >=20 > > As you say, an unsolicited incoming packet doesn't get marked. However = it > > creates a conntrack record with zero mark. What you then do is to mark = the > > conntrack record later so that all subsequent packets on that connectio= n get > > marked by 'action connmark'. So the first packet gets classified on ifb= to > > some low priority queue, but subsequent ones go where they should. > >=20 > > I do this for incoming ssh and VPN connections, though I'm using > > htb/fq_codel rather than cake at the moment. > > =20 >=20 > Thank you John, that has confirmed my understanding that in essence it=E2= =80=99s not possible in linux to mangle/mark the first packet on ingress an= d you ideally need the DSCP to be correct. >=20 > My router threw me another curve ball in that it was classifying incoming= packets correctly but outgoing acks weren=E2=80=99t. Since (ingress) conn= marks were based on DSCP values I really couldn=E2=80=99t understand how th= e connection had been marked correctly for ingress but the egress was wrong. >=20 > This turned out to be fallout from openwrt=E2=80=99s software flow offloa= d feature which bypasses some more of the stack. So ingress classification= was based on connmarks whilst the egress was based on DSCP and because of = the flow offloading the DSCP values weren=E2=80=99t being mangled after the= first few packets. >=20 > At this stage I=E2=80=99m wondering if its possible to get tc/cake to cla= ssify egress based on connmarks instead of relying on DSCP but my tc filter= syntax is failing me at the moment :-) It is possible to use a tc ingress filter to remark DSCP.