netdev - Re: [PATCH net] tcp: restrict F-RTO to work-around broken middle-boxes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CADVnQy=g8PJ2MdDSRO-cY4-B3yVcXvL4Zo-9Qu69xsKp0AaQQA@mail.gmail.com>
Date:   Mon, 19 Feb 2018 08:38:50 -0500
From:   Neal Cardwell <ncardwell@...gle.com>
To:     Teodor Milkov <tm@....bg>
Cc:     Netdev <netdev@...r.kernel.org>, Yuchung Cheng <ycheng@...gle.com>
Subject: Re: [PATCH net] tcp: restrict F-RTO to work-around broken middle-boxes

On Sun, Feb 18, 2018 at 4:02 PM, Teodor Milkov <tm@....bg> wrote:
> Hello,
>
> I've numerous reports from Windows users that after kernel upgrade from 4.9
> to 4.14 they experienced major slow downs and transfer stalls.
>
> After some digging, I found that the slowness starts with this commit:
>
>  tcp: extend F-RTO to catch more spurious timeouts (89fe18e44)
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=89fe18e44f7ee5ab1c90d0dff5835acee7751427
>
> Which is partially reverted later with this one:
>
>  tcp: restrict F-RTO to work-around broken middle-boxes (cc663f4d4)
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cc663f4d4c97b7297fb45135ab23cfd508b35a77
>
> But, still, we had stalls until I fully reverted 89fe18e44.

Thanks for the report. Do you have any other details that might help
evaluate this issue? Any packet traces, by any chance? Were the
affected connections web browsing, videos, file transfer, etc? Were
there non-Windows users in this population that did not seem to be
affected by the stalls? Was the bottleneck primarily Ethernet, wifi,
cellular, cable modem, etc? Any middleboxes (firewall, NAT, etc)
between the servers and users? Does "stall" mean that the connection
permanently froze, or temporarily slowed down but eventually
recovered?

Thanks!

neal