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

From: Matt Corallo <netdev-list@mattcorallo.com>
To: Eric Dumazet <edumazet@google.com>
Cc: Willy Tarreau <w@1wt.eu>, "David S. Miller" <davem@davemloft.net>,
	netdev <netdev@vger.kernel.org>,
	Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>,
	Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>,
	Keyu Man <kman001@ucr.edu>
Subject: Re: [PATCH net-next] Reduce IP_FRAG_TIME fragment-reassembly timeout to 1s, from 30s
Date: Mon, 3 May 2021 10:30:31 -0400	[thread overview]
Message-ID: <9d2b9d8c-e1b7-af7b-e881-79d2c664aac7@bluematt.me> (raw)
In-Reply-To: <f7d0a759-a8ab-2524-4939-095544d12913@bluematt.me>

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