netdev - Re: [PATCH net-next] Reduce IP_FRAG_TIME fragment-reassembly timeout to 1s, from 30s

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <055d0512-216c-9661-9dd4-007c46049265@bluematt.me>
Date:   Wed, 28 Apr 2021 10:28:22 -0400
From:   Matt Corallo <netdev-list@...tcorallo.com>
To:     Willy Tarreau <w@....eu>
Cc:     Eric Dumazet <edumazet@...gle.com>,
        "David S. Miller" <davem@...emloft.net>,
        netdev <netdev@...r.kernel.org>,
        Alexey Kuznetsov <kuznet@....inr.ac.ru>,
        Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
        Keyu Man <kman001@....edu>
Subject: Re: [PATCH net-next] Reduce IP_FRAG_TIME fragment-reassembly timeout
 to 1s, from 30s

On 4/28/21 10:13, Willy Tarreau wrote:
> On Wed, Apr 28, 2021 at 10:09:00AM -0400, Matt Corallo wrote:
> Regardless of retransmits, large RTTs are often an indication of buffer bloat
> on the path, and this can take some fragments apart, even worse when you mix
> this with multi-path routing where some fragments may take a short path and
> others can take a congested one. In this case you'll note that the excessive
> buffer time can become a non-negligible part of the observed RTT, hence the
> indirect relation between the two.

Right, buffer bloat is definitely a concern. Would it make more sense to reduce the default to somewhere closer to 3s?

More generally, I find this a rather interesting case - obviously breaking *deployed* use-cases of Linux is Really Bad, 
but at the same time, the internet has changed around us and suddenly other reasonable use-cases of Linux (ie as a 
router processing real-world consumer flows - in my case a stupid DOCSIS modem dropping 1Mbps from its measly 20Mbps 
limit) have slowly broken instead.

Matt