From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9FE8CC433EF for ; Sun, 17 Oct 2021 22:04:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7BFCA61078 for ; Sun, 17 Oct 2021 22:04:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344747AbhJQWGe (ORCPT ); Sun, 17 Oct 2021 18:06:34 -0400 Received: from mail.netfilter.org ([217.70.188.207]:53358 "EHLO mail.netfilter.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1344746AbhJQWGe (ORCPT ); Sun, 17 Oct 2021 18:06:34 -0400 Received: from netfilter.org (unknown [78.30.32.163]) by mail.netfilter.org (Postfix) with ESMTPSA id E352A605E1; Mon, 18 Oct 2021 00:02:41 +0200 (CEST) Date: Mon, 18 Oct 2021 00:04:19 +0200 From: Pablo Neira Ayuso To: Maciej =?utf-8?Q?=C5=BBenczykowski?= Cc: Florian Westphal , Linux Network Development Mailing List , Netfilter Development Mailing List Subject: Re: [PATCH netfilter] netfilter: conntrack: udp: generate event on switch to stream timeout Message-ID: References: <20211015090934.2870662-1-zenczykowski@gmail.com> <20211015095716.GH2942@breakpoint.cc> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Fri, Oct 15, 2021 at 03:15:07AM -0700, Maciej Żenczykowski wrote: > On Fri, Oct 15, 2021 at 2:57 AM Florian Westphal wrote: > > Maciej Żenczykowski wrote: [...] > A udp flow becoming bidirectional seems like an important event to > notify about... > Afterall, the UDP flow might become a stream 29 seconds after it > becomes bidirectional... > That seems like a pretty long time (and it's user configurable to be > even longer) to delay the notification. > > I imagine the pair of you know best whether 2 events or delay assured > event until stream timeout is applied makes more sense... This 2 events looks awkward to me, currently the model we have to report events is: - status bits are updated - flow has changed protocol state (TCP). but in this case, this is reporting a timer update. Timeout updates are not reported on events, since this would trigger too many events one per packet. What's the concern with delaying the IPS_ASSURED bit? By setting a lower timeout (30 second) my understanding is that this flow is less important to those that are in the stream state (120s), so these should also be candidate to be removed by early_drop. IIRC, the idea behind the stream concept is to reduce lifetime of shortlived UDP flows to release slots from the conntrack table earlier.