From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl0-f51.google.com ([209.85.160.51]:35820 "EHLO mail-pl0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933468AbeCGP6Z (ORCPT ); Wed, 7 Mar 2018 10:58:25 -0500 Received: by mail-pl0-f51.google.com with SMTP id w22-v6so1549593pll.2 for ; Wed, 07 Mar 2018 07:58:25 -0800 (PST) Message-ID: <1520438302.109662.42.camel@gmail.com> Subject: Re: [PATCH net 5/5] tcp: send real dupACKs by locking advertized window for non-SACK flows From: Eric Dumazet To: Ilpo =?ISO-8859-1?Q?J=E4rvinen?= , netdev@vger.kernel.org Date: Wed, 07 Mar 2018 07:58:22 -0800 In-Reply-To: <1520427569-14365-6-git-send-email-ilpo.jarvinen@helsinki.fi> References: <1520427569-14365-1-git-send-email-ilpo.jarvinen@helsinki.fi> <1520427569-14365-6-git-send-email-ilpo.jarvinen@helsinki.fi> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: netdev-owner@vger.kernel.org List-ID: On Wed, 2018-03-07 at 14:59 +0200, Ilpo Järvinen wrote: > Currently, the TCP code is overly eager to update window on > every ACK. It makes some of the ACKs that the receiver should > sent as dupACKs look like they update window update that are > not considered real dupACKs by the non-SACK sender-side code. > > Make sure that when an ofo segment is received, no change to > window is applied if we are going to send a dupACK. It's ok > to change the window for non-dupACKs (such as the first ACK > after ofo arrivals start if that ACK was using delayed ACKs). This looks dangerous to me. We certainly want to lower the window at some point, or risk expensive pruning and/or drops. It is not clear by reading your changelog/patch, but it looks like some malicious peers could hurt us. By current standards, non TCP sack flows are not worth any potential issues.