On 3/29/21 20:04, Matt Corallo wrote:
This issue largely goes away when setting net.ipv4.ipfrag_time to 0/1.
Quick correction - the issue is reduced when set to 1 (as you might expect, you don't see as much loss if you wipe the
fragment buffer every second) but if you set it to zero hosts ran
IP_FRAG_TIME defaults to 30 full long seconds to wait for reassembly of fragments. In practice, with the default values,
if I send enough fragments over a line that there is material loss, its not strange to see fragments be completely
dropped for the remainder of a 30 second time period before r
