Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp598453imm; Mon, 2 Jul 2018 18:19:51 -0700 (PDT) X-Google-Smtp-Source: AAOMgpcbEuxUv1RkYTHQivCZx8P+LBgQnmVLMAqpC6phg7ugHu4TIW5xJ9MiIISCv0h2KHBJGEN/ X-Received: by 2002:a63:a919:: with SMTP id u25-v6mr13038266pge.211.1530580791538; Mon, 02 Jul 2018 18:19:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1530580791; cv=none; d=google.com; s=arc-20160816; b=paV3QLv2F74e3jCaCsICaIgi3lqCuLhxjjL/RzAhczppFkPIrA34YxTjNBzDX22Tfj ozhuTM2QsICnptb1CSJinlpc7S3If0yhEDLteya4g6AqfRAvIv7oISyb6+AkSQNrQp5P DuQcFVZuSK0Y89pF8ehgj0Lnokv2RiNqfzhAcfGCUEP0wS7FQ6SAGjNSvWvPDxf/OYXV 43TSsSfFnHvKPERmcSi8t0GYnRFucw0dybhkckEHcPWdvvppXTHuFjftuJBKP2o4hBcq rkGvPb1+kng+WToI3bt8H4VZLo9VqiI965FDRePcp7QFM/Q9cUzAOmeYi57RHyJEzSF7 THmQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :dkim-signature:arc-authentication-results; bh=TRFijuv2DkpGYaIiCitgQnloeHIS2Toj7e9lhhstwTQ=; b=meAtzOecjo6zrcBroEScIChq48pYuuhDXQDBgOBhwWmBqzXBrEkXK4saZjPTHdA5Ul dah11DZn974nZwJsBTbYHLhC2pe5qoNnP78jhjhKXedfDdwtOBvzi3g96oGIuiPCEvJb ONZt1IQwGdwVNtZd0wajCuDduuDwentdoVeIPw47iD3LoEILFKL4FgT1c/hR3fTVNJzf IKsuK6OD5uS6oT6nyyaxzORFWTuAPlFc0JPrATWn+OP3CalIJMJOaxy2waDceW3zYFmQ m1zxKC5HGVA+32pXwqzOkWNfGLTewxWhkpX1K79c1fh6qQgJSCE6ohFinBAKZZj1BfZG W+og== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=oLSZlBEz; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r6-v6si4264613pgm.647.2018.07.02.18.19.37; Mon, 02 Jul 2018 18:19:51 -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; dkim=pass header.i=@gmail.com header.s=20161025 header.b=oLSZlBEz; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932221AbeGCBRv (ORCPT + 99 others); Mon, 2 Jul 2018 21:17:51 -0400 Received: from mail-pf0-f174.google.com ([209.85.192.174]:34311 "EHLO mail-pf0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932098AbeGCBRt (ORCPT ); Mon, 2 Jul 2018 21:17:49 -0400 Received: by mail-pf0-f174.google.com with SMTP id e10-v6so156863pfn.1; Mon, 02 Jul 2018 18:17:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id; bh=TRFijuv2DkpGYaIiCitgQnloeHIS2Toj7e9lhhstwTQ=; b=oLSZlBEzEWzVqaglmcOZycUcrXeHzt3ztYnr/ucFRf62UehyINlSUJ8wqzVgQvlzHP vhkMBGKetENlxz59XEnSLi76KHsLIfU82kNOexLmO67G2d70RlGdxIbVHdME9fTxEVqF xpWcQAh/APtRq57M5H+Bs1G93fuGO5QN22zmW/ETi9DAXBuI/qLgUWDTvmipr/+CDWOX CLC4Wq76+NPbdcy0Jdwb28wf+LckP0J7MgwoJWdsD7vCEN9fkf2290834cmLDMqIejMj phvDVd2Q3U7v+E/eMZyPgutcz+rmPd0eE7mz4quCCIpAZd/DCzrpn5fZHcFp9+vYTPDW 6UEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=TRFijuv2DkpGYaIiCitgQnloeHIS2Toj7e9lhhstwTQ=; b=ZgAcJriFVXAIVwfUW6bfEKsDIRkUlrIpUzY8usmb7iUseec/+VaenUY45NY9eI9odG jj1Ad7xqBFvttWG2Ic2jbARJ+NLL2RFzcD6Ya5yPiZ5LdaV+o3KZtZmIukkr/v1QOxDY s6kaUv3QK7EiLPJUmGQnFrO5QavVxYRq4dkOrVvgZLCinuPoUCEXlF81BF6Wv/0AP3MM mIH9J5REHc8nRZiPsR//S5Ggsu6/7NziWPpiPLdfDhmRLs49rZcrfDP4567L73wye63J 4LpP3PHM61/6BBhgX3TPgCNEMfeGQSJMUfKgKucKZADI5Ef4/76dG+itFDyYbWQoP5dn Tdpg== X-Gm-Message-State: APt69E116yL2vyOD/syB/EJY7vRrh49OIBft/v3PBscvnSQ2zS+2O8We rJjrNOOT+kZRf8scrRvhJyIRum8Q X-Received: by 2002:a62:33c4:: with SMTP id z187-v6mr27699453pfz.190.1530580668747; Mon, 02 Jul 2018 18:17:48 -0700 (PDT) Received: from 192-168-1-6.tpgi.com.com (110-175-8-199.static.tpgi.com.au. [110.175.8.199]) by smtp.gmail.com with ESMTPSA id h12-v6sm25202970pfi.114.2018.07.02.18.17.44 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 02 Jul 2018 18:17:47 -0700 (PDT) From: Jon Maxwell To: davem@davemloft.net Cc: edumazet@google.com, kuznet@ms2.inr.ac.ru, yoshfuji@linux-ipv6.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, jmaxwell@redhat.com Subject: [PATCH net-next] tcp: Improve setsockopt() TCP_USER_TIMEOUT accuracy Date: Tue, 3 Jul 2018 11:17:26 +1000 Message-Id: <20180703011726.8301-1-jmaxwell37@gmail.com> X-Mailer: git-send-email 2.13.6 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Every time the TCP retransmission timer fires. It checks to see if there is a timeout before scheduling the next retransmit timer. The retransmit interval between each retransmission increases exponentially. The issue is that in order for the timeout to occur the retransmit timer needs to fire again. If the user timeout check happens after the 9th retransmit for example. It needs to wait for the 10th retransmit timer to fire in order to evaluate whether a timeout has occurred or not. If the interval is large enough then the timeout will be inaccurate. For example with a TCP_USER_TIMEOUT of 10 seconds without patch: 1st retransmit: 22:25:18.973488 IP host1.49310 > host2.search-agent: Flags [.] Last retransmit: 22:25:26.205499 IP host1.49310 > host2.search-agent: Flags [.] Timeout: send: Connection timed out Sun Jul 1 22:25:34 EDT 2018 We can see that last retransmit took ~7 seconds. Which pushed the total timeout to ~15 seconds instead of the expected 10 seconds. This gets more inaccurate the larger the TCP_USER_TIMEOUT value. As the interval increases. Fix this by recalculating the last retransmit interval so that it fires when the timeout should occur. Only implement when icsk->icsk_user_timeout is set. Test results with the patch is the expected 10 second timeout: 1st retransmit: 01:37:59.022555 IP host1.49310 > host2.search-agent: Flags [.] Last retransmit: 01:38:06.486558 IP host1.49310 > host2.search-agent: Flags [.] Timeout: send: Connection timed out Mon Jul 2 01:38:09 EDT 2018 Signed-off-by: Jon Maxwell --- net/ipv4/tcp_timer.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/net/ipv4/tcp_timer.c b/net/ipv4/tcp_timer.c index 3b3611729928..94491a481722 100644 --- a/net/ipv4/tcp_timer.c +++ b/net/ipv4/tcp_timer.c @@ -407,6 +407,7 @@ void tcp_retransmit_timer(struct sock *sk) struct tcp_sock *tp = tcp_sk(sk); struct net *net = sock_net(sk); struct inet_connection_sock *icsk = inet_csk(sk); + __u32 time_remaining = 0; if (tp->fastopen_rsk) { WARN_ON_ONCE(sk->sk_state != TCP_SYN_RECV && @@ -535,6 +536,12 @@ void tcp_retransmit_timer(struct sock *sk) /* Use normal (exponential) backoff */ icsk->icsk_rto = min(icsk->icsk_rto << 1, TCP_RTO_MAX); } + if (icsk->icsk_user_timeout) { + time_remaining = jiffies_to_msecs(icsk->icsk_user_timeout) - + (tcp_time_stamp(tcp_sk(sk)) - tcp_sk(sk)->retrans_stamp); + if (time_remaining < icsk->icsk_rto) + icsk->icsk_rto = time_remaining; + } inet_csk_reset_xmit_timer(sk, ICSK_TIME_RETRANS, icsk->icsk_rto, TCP_RTO_MAX); if (retransmits_timed_out(sk, net->ipv4.sysctl_tcp_retries1 + 1, 0)) __sk_dst_reset(sk); -- 2.13.6