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: <3b2a1a75-869d-2908-7c18-903728940961@del.bg>
Date:   Wed, 21 Feb 2018 14:38:21 +0200
From:   Teodor Milkov <tm@....bg>
To:     Netdev <netdev@...r.kernel.org>
Cc:     Neal Cardwell <ncardwell@...gle.com>,
        Yuchung Cheng <ycheng@...gle.com>
Subject: Re: [PATCH net] tcp: restrict F-RTO to work-around broken
 middle-boxes

On 19.02.2018 20:05, Neal Cardwell wrote:
> On Mon, Feb 19, 2018 at 11:17 AM, Teodor Milkov <tm@....bg> wrote:
>> On 19.02.2018 15:38, Neal Cardwell wrote:
>>> 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?
>>
>> I'm sorry I didn't provide more info. It was long session.
>>
>>> Any packet traces, by any chance?
>>
>> I'll try and obtain one.
> Great! Yes, if you could obtain a sender-side tcpdump that captured
> one of these slow-down/stalls, that would be fantastic. It would be
> great to be able to understand what's going on.
>
> We only need headers, so something like the following would be fine:
>
>     tcpdump -c2000000 -w /tmp/test.pcap -s 120 -i $ETH_DEVICE port $PORT
>
> Then if you could post on a web server or Google drive, etc, that'd be great.

Here they are:


  http://vps3.avodz.org/tmp/frto-4.14.11-linux.pcap.xz - 3.3 MB/s

  http://vps3.avodz.org/tmp/frto-4.14.11-windows.pcap.xz - connection 
completely froze and eventually timed out

  http://vps3.avodz.org/tmp/frto-4.14.20+revert-windows.pcap.xz - 5+ 
MB/s, which almost saturated the link