[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0d41553d-69ac-651c-9c41-743391619a40@vsen.dk>
Date: Fri, 28 Jul 2017 08:36:49 +0200
From: Klavs Klavsen <kl@...n.dk>
To: Willy Tarreau <w@....eu>
Cc: Eric Dumazet <eric.dumazet@...il.com>, netdev@...r.kernel.org
Subject: Re: TCP fast retransmit issues
The network guys know what caused it.
Appearently on (atleast some) Cisco equipment the feature:
TCP Sequence Number Randomization
is enabled by default.
It would most definetely be beneficial if Linux handled SACK "not
working" better than it does - but then I might never have found the
culprit who destroyed SACK :)
Willy Tarreau wrote on 26-07-2017 16:38:
> On Wed, Jul 26, 2017 at 04:25:29PM +0200, Klavs Klavsen wrote:
>> Thank you very much guys for your insight.. its highly appreciated.
>>
>> Next up for me, is waiting till the network guys come back from summer
>> vacation, and convince them to sniff on the devices in between to pinpoint
>> the culprit :)
> That said, Eric, I'm a bit surprized that it completely stalls. Shouldn't
> the sender end up retransmitting unacked segments after seeing a certain
> number of ACKs not making progress ? Or maybe this is disabled when SACKs
> are in use but it seems to me that once invalid SACKs are ignored we should
> ideally fall back to the normal way to deal with losses. Here the server
> ACKed 3903858556 for the first time at 15:59:54.292743 and repeated this
> one 850 times till 16:01:17.296407 but the client kept sending past this
> point probably due to a huge window, so this looks suboptimal to me.
>
> Willy
--
Regards,
Klavs Klavsen, GSEC - kl@...n.dk - http://www.vsen.dk - Tlf. 61281200
"Those who do not understand Unix are condemned to reinvent it, poorly."
--Henry Spencer
Powered by blists - more mailing lists