[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210428141319.GA7645@1wt.eu>
Date: Wed, 28 Apr 2021 16:13:19 +0200
From: Willy Tarreau <w@....eu>
To: Matt Corallo <netdev-list@...tcorallo.com>
Cc: Eric Dumazet <edumazet@...gle.com>,
"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 Wed, Apr 28, 2021 at 10:09:00AM -0400, Matt Corallo wrote:
>
>
> On 4/28/21 08:20, Eric Dumazet wrote:
> > This is going to break many use cases.
> >
> > I can certainly say that in many cases, we need more than 1 second to
> > complete reassembly.
> > Some Internet users share satellite links with 600 ms RTT, not
> > everybody has fiber links in 2021.
>
> I'm curious what RTT has to do with it? Frags aren't resent, so there's no
> RTT you need to wait for, the question is more your available bandwidth and
> how much packet reordering you see, which even for many sat links isn't zero
> anymore (better, in-flow packet reordering is becoming more and more rare!).
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.
Willy
Powered by blists - more mailing lists