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 X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D0F16C433ED for ; Mon, 3 May 2021 14:30:43 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 8A811611AD for ; Mon, 3 May 2021 14:30:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229717AbhECObe (ORCPT ); Mon, 3 May 2021 10:31:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49472 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229721AbhECOb2 (ORCPT ); Mon, 3 May 2021 10:31:28 -0400 Received: from mail.as397444.net (mail.as397444.net [IPv6:2620:6e:a000:dead:beef:15:bad:f00d]) by lindbergh.monkeyblade.net (Postfix) with UTF8SMTPS id 5DA4DC06174A for ; Mon, 3 May 2021 07:30:33 -0700 (PDT) Received: by mail.as397444.net (Postfix) with UTF8SMTPSA id DBE86567A1D; Mon, 3 May 2021 14:30:31 +0000 (UTC) X-DKIM-Note: Keys used to sign are likely public at https://as397444.net/dkim/ DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mattcorallo.com; s=1620050464; t=1620052231; bh=xR+taIqVTqdoezKf0Cn70l4t09waj7N8danorsao6y8=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=l3/bqHB0ZKQ33suOhKqQi/kefUoW9+onCVjHEgrZvGWO7DW3SZYgoJ69t7vLdhrKv LpHJNdagp/ctd3VPu3Q8KNuJ4883CPVnGyuw0vvOyJqpWK/rIeVMvriaxhU6kP6mWO 7VjhBtr9xTfb/am117XNuvpKfTuQqW39g8ojhm0fyGbitXt01VU0zG1ORWN4UBCIk/ xxAKOWpzUQDCl0dXwNIBXIBVDTIu//gEgBOLGB7SDz6T/wgjxSWNtVWHzD1AspXd5Z 7IYFJWCHkJR36aDOuoVkjxm5fkVAQFyZ5ve2STYv1rUy/5TBqJ6V7urlEW4aBBEst2 qDc8S+XD1mmQg== Message-ID: <9d2b9d8c-e1b7-af7b-e881-79d2c664aac7@bluematt.me> Date: Mon, 3 May 2021 10:30:31 -0400 MIME-Version: 1.0 Subject: Re: [PATCH net-next] Reduce IP_FRAG_TIME fragment-reassembly timeout to 1s, from 30s Content-Language: en-US To: Eric Dumazet Cc: Willy Tarreau , "David S. Miller" , netdev , Alexey Kuznetsov , Hideaki YOSHIFUJI , Keyu Man References: <0cb19f7e-a9b3-58f8-6119-0736010f1326@bluematt.me> <20210428141319.GA7645@1wt.eu> <055d0512-216c-9661-9dd4-007c46049265@bluematt.me> <64829c98-e4eb-6725-0fee-dc3c6681506f@bluematt.me> <1baf048d-18e8-3e0c-feee-a01b381b0168@bluematt.me> From: Matt Corallo In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org At the risk of being obnoxious here - that's a "no" to reconsidering the tradeoffs picked 20 years ago? I don't want to waste time if the answer is a complete "no", but if it isn't I'm happy to try to figure out what exactly the right tradeoffs are here, and spend time implementing things. Thanks, Matt On 4/30/21 14:04, Matt Corallo wrote: > On 4/30/21 13:53, Matt Corallo wrote: >> >> Buffer bloat exists, but so do networks that will happily drop 1Mbps of packets. The first has always been true, the >> second only more recently has become more and more common (both due to network speed and application behavior). > > It may be worth noting, to further highlight the tradeoffs made here - that, given a constant amount of memory allocated > for fragment reassembly, *under* estimating the timeout will result in only loss of some % of packets which were > reordered in excess of the timeout, whereas *over* estimating the timeout results in complete blackhole for up to the > timeout in the face of material packet loss. > > This asymmetry is why I suggested possibly random eviction could be useful as a different set of trade-offs, but I'm > certainly not qualified to make that determination. > > Thanks again for your time and consideration, > Matt