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

[Eric Dumazet <edumazet@google.com>]

On Wed, Apr 28, 2021 at 4:28 PM Matt Corallo
<netdev-list@mattcorallo.com> wrote:
>
>
>
> 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

I have been working in wifi environments (linux conferences) where RTT
could reach 20 sec, and even 30 seconds, and this was in some very
rich cities in the USA.

Obviously, when a network is under provisioned by 50x factor, you
_need_ more time to complete fragments.

For some reason, the crazy IP reassembly stuff comes every couple of
years, and it is now a FAQ.

The Internet has changed for the  lucky ones, but some deployments are
using 4Mbps satellite connectivity, shared by hundreds of people.
I urge application designers to _not_ rely on doomed frags, even in
controlled networks.