netdev - Re: [PATCH net-next v2] tcp: force cwnd at least 2 in tcp_cwnd

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-next>] [day] [month] [year] [list]

Message-ID: <CADVnQy=MsiEBCr+Mnp97mp0MxDqrA+_KiZEQehgcDfe9L-hghQ@mail.gmail.com>
Date:   Thu, 28 Jun 2018 16:47:38 -0400
From:   Neal Cardwell <ncardwell@...gle.com>
To:     Lawrence Brakmo <brakmo@...com>
Cc:     Yuchung Cheng <ycheng@...gle.com>,
        Matt Mathis <mattmathis@...gle.com>,
        Netdev <netdev@...r.kernel.org>,
        Kernel Team <Kernel-team@...com>, bmatheny@...com, ast@...com,
        Eric Dumazet <eric.dumazet@...il.com>,
        Wei Wang <weiwan@...gle.com>,
        Steve Ibanez <sibanez@...nford.edu>,
        Yousuk Seung <ysseung@...gle.com>
Subject: Re: [PATCH net-next v2] tcp: force cwnd at least 2 in tcp_cwnd_reduction

On Thu, Jun 28, 2018 at 4:20 PM Lawrence Brakmo <brakmo@...com> wrote:
>
> I just looked at 4.18 traces and the behavior is as follows:
>
>    Host A sends the last packets of the request
>
>    Host B receives them, and the last packet is marked with congestion (CE)
>
>    Host B sends ACKs for packets not marked with congestion
>
>    Host B sends data packet with reply and ACK for packet marked with congestion (TCP flag ECE)
>
>    Host A receives ACKs with no ECE flag
>
>    Host A receives data packet with ACK for the last packet of request and has TCP ECE bit set
>
>    Host A sends 1st data packet of the next request with TCP flag CWR
>
>    Host B receives the packet (as seen in tcpdump at B), no CE flag
>
>    Host B sends a dup ACK that also has the TCP ECE flag
>
>    Host A RTO timer fires!
>
>    Host A to send the next packet
>
>    Host A receives an ACK for everything it has sent (i.e. Host B did receive 1st packet of request)
>
>    Host A send more packets…

Thanks, Larry! This is very interesting. I don't know the cause, but
this reminds me of an issue  Steve Ibanez raised on the netdev list
last December, where he was seeing cases with DCTCP where a CWR packet
would be received and buffered by Host B but not ACKed by Host B. This
was the thread "Re: Linux ECN Handling", starting around December 5. I
have cc-ed Steve.

I wonder if this may somehow be related to the DCTCP logic to rewind
tp->rcv_nxt and call tcp_send_ack(), and then restore tp->rcv_nxt, if
DCTCP notices that the incoming CE bits have been changed while the
receiver thinks it is holding on to a delayed ACK (in
dctcp_ce_state_0_to_1() and dctcp_ce_state_1_to_0()). I wonder if the
"synthetic" call to tcp_send_ack() somehow has side effects in the
delayed ACK state machine that can cause the connection to forget that
it still needs to fire a delayed ACK, even though it just sent an ACK
just now.

neal