Re: Linux ECN Handling

From: Neal Cardwell <ncardwell@google.com>
To: Steve Ibanez <sibanez@stanford.edu>
Cc: Eric Dumazet <edumazet@google.com>,
	Yuchung Cheng <ycheng@google.com>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Netdev <netdev@vger.kernel.org>, Florian Westphal <fw@strlen.de>,
	Mohammad Alizadeh <alizadeh@csail.mit.edu>,
	Lawrence Brakmo <brakmo@fb.com>
Subject: Re: Linux ECN Handling
Date: Tue, 5 Dec 2017 15:04:57 -0500	[thread overview]
Message-ID: <CADVnQy=9xxQ2XH0rKhR+kHp6J9nOvM7e=6z-AJPAiTaap0e_bA@mail.gmail.com> (raw)
In-Reply-To: <CACJspmLaxdHoa63jCuD-mKJS35BZ69b9qw3tEZjFxbUNb3PSHg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1080 bytes --]

On Tue, Dec 5, 2017 at 2:36 PM, Steve Ibanez <sibanez@stanford.edu> wrote:
> Hi Neal,
>
> I've included a link to small trace of 13 packets which is different
> from the screenshot I attached in my last email, but shows the same
> sequence of events. It's a bit hard to read the tcptrace due to the
> 300ms timeout, so I figured this was the best approach.
>
> slice.pcap: https://drive.google.com/open?id=1hYXbUClHGbQv1hWG1HZWDO2WYf30N6G8

Thanks for the trace! Attached is a screen shot (first screen shot is
for the arriving packets with CWR; second is after the RTO). The
sender behavior looks reasonable. I don't see why the receiver is not
ACKing. As you say, it does look like a receiver bug. You could try
adding instrumentation to try to isolate why the receiver is not
sending an ACK immediately. You might instrument __tcp_ack_snd_check()
and tcp_send_delayed_ack() so that when the most recent incoming
packet had cwr set they printk to log what they are deciding in this
case. Perhaps the tcp_send_delayed_ack()  code is hitting the max_ato
= HZ / 2 code path?

neal

[-- Attachment #2: cwr-no-ack-1.png --]
[-- Type: image/png, Size: 9725 bytes --]

[-- Attachment #3: cwr-no-ack-2.png --]
[-- Type: image/png, Size: 11703 bytes --]