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] [day] [month] [year] [list]

Message-ID: <9d2b9d8c-e1b7-af7b-e881-79d2c664aac7@bluematt.me>
Date:   Mon, 3 May 2021 10:30:31 -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

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