Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp895950imm; Wed, 13 Jun 2018 09:57:32 -0700 (PDT) X-Google-Smtp-Source: ADUXVKJt1HpJyz+iYoyrmQGDJIo4I5ZiTHfSR+rTSUKrfsQp2NjQ3UGEhFpDj47vwT9CnRrs+LmG X-Received: by 2002:a63:5fc1:: with SMTP id t184-v6mr4797644pgb.132.1528909052892; Wed, 13 Jun 2018 09:57:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528909052; cv=none; d=google.com; s=arc-20160816; b=jJTJw2xUvBOfEiUXLiU0xIiSJA0/5f6fCPNAGG/WRRHSs5B26STRNvJqCPIVdpfMs+ km71AdcRqUqZHBZqXwWFbpOelzJGieqCaxVxUSIhsGRoxcpC7SmfxIgnvOsJ96n7N3IZ mcrxEMWrY3vLDM9F0Mz0RRpW99GEJPnR4xkxssHqg/vTM9lrF00tMywKWCifBSrEiEWk os+Pss0kYZFAg8tSkENMDpxHFvaLZZxft7Xs1C2LqmRbTBiYjQOBWDfN/WX6ZvwhrPSk rzlg30WohMUUE1o64mx9QCOpLcTVQMFi1Nk3q1cEBYV8gMkYyG4dWCc00p6+Z525ajPb 4SDQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:date:message-id:references:in-reply-to:cc :to:subject:from:arc-authentication-results; bh=Hqx65vfnynxElHAp0CJzetiN0fIIJU4hjVIzc70oRY8=; b=dzbKvON5eBGyfR8OcOUPgcI3jfFt8w/mD5OTt8eEN6pkCfoALVIzcWKAxekR5EyF10 fKZcNYx+SBdQIOuL65AV5wrvzOGHryZFY5I6MpydybUJ9y13rP/Y8GMzySynfNWjy6aM 4X+nY6j0c5gnTWqSS8pz2kb0pUlCvhDb/yNM40ymJCxiG+Otj1EIKiq3hXWs5eeZwiTY dXxvCqIhOTUfM0a8T/zouqmFODLXfK1+2CMTaAgUeG7Py07ZbGCdc9wmkIdF0gmx5eIV L7FJZE8SGXwR9/xyJqvhO4Zzrkpsl9duxAE42n+sbWChrdFb1UW7cLyyQVz81fa7mke7 yuJA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 60-v6si3376082ple.65.2018.06.13.09.57.17; Wed, 13 Jun 2018 09:57:32 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935402AbeFMQzq (ORCPT + 99 others); Wed, 13 Jun 2018 12:55:46 -0400 Received: from mx2.suse.de ([195.135.220.15]:35880 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935035AbeFMQzp (ORCPT ); Wed, 13 Jun 2018 12:55:45 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (charybdis-ext-too.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id AF5C7AC25; Wed, 13 Jun 2018 16:55:43 +0000 (UTC) Received: by unicorn.suse.cz (Postfix, from userid 1000) id 0F92DA09E2; Wed, 13 Jun 2018 18:55:43 +0200 (CEST) From: Michal Kubecek Subject: [RFC PATCH RESEND] tcp: avoid F-RTO if SACK and timestamps are disabled To: netdev@vger.kernel.org Cc: Eric Dumazet , Yuchung Cheng , Ilpo Jarvinen , linux-kernel@vger.kernel.org In-Reply-To: <20180613164802.99B89A09E2@unicorn.suse.cz> References: <20180613164802.99B89A09E2@unicorn.suse.cz> Message-Id: <20180613165543.0F92DA09E2@unicorn.suse.cz> Date: Wed, 13 Jun 2018 18:55:43 +0200 (CEST) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org When F-RTO algorithm (RFC 5682) is used on connection without both SACK and timestamps (either because of (mis)configuration or because the other endpoint does not advertise them), specific pattern loss can make RTO grow exponentially until the sender is only able to send one packet per two minutes (TCP_RTO_MAX). One way to reproduce is to - make sure the connection uses neither SACK nor timestamps - let tp->reorder grow enough so that lost packets are retransmitted after RTO (rather than when high_seq - snd_una > reorder * MSS) - let the data flow stabilize - drop multiple sender packets in "every second" pattern - either there is no new data to send or acks received in response to new data are also window updates (i.e. not dupacks by definition) In this scenario, the sender keeps cycling between retransmitting first lost packet (step 1 of RFC 5682), sending new data by (2b) and timing out again. In this loop, the sender only gets (a) acks for retransmitted segments (possibly together with old ones) (b) window updates Without timestamps, neither can be used for RTT estimator and without SACK, we have no newly sacked segments to estimate RTT either. Therefore each timeout doubles RTO and without usable RTT samples so that there is nothing to counter the exponential growth. While disabling both SACK and timestamps doesn't make any sense, the resulting behaviour is so pathological that it deserves an improvement. (Also, both can be disabled on the other side.) Avoid F-RTO algorithm in case both SACK and timestamps are disabled so that the sender falls back to traditional slow start retransmission. Signed-off-by: Michal Kubecek --- net/ipv4/tcp_input.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c index 355d3dffd021..ed603f987b72 100644 --- a/net/ipv4/tcp_input.c +++ b/net/ipv4/tcp_input.c @@ -2001,7 +2001,8 @@ void tcp_enter_loss(struct sock *sk) */ tp->frto = net->ipv4.sysctl_tcp_frto && (new_recovery || icsk->icsk_retransmits) && - !inet_csk(sk)->icsk_mtup.probe_size; + !inet_csk(sk)->icsk_mtup.probe_size && + (tcp_is_sack(tp) || tp->rx_opt.tstamp_ok); } /* If ACK arrived pointing to a remembered SACK, it means that our -- 2.17.1