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]

Date:   Fri, 30 Apr 2021 14:04:34 -0400
From:   Matt Corallo <netdev-list@...tcorallo.com>
To:     Eric Dumazet <edumazet@...gle.com>
Cc:     Willy Tarreau <w@....eu>, "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/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