From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl0-x22e.google.com (mail-pl0-x22e.google.com [IPv6:2607:f8b0:400e:c01::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id ECC723B2A4 for ; Thu, 30 Nov 2017 10:55:22 -0500 (EST) Received: by mail-pl0-x22e.google.com with SMTP id x22so4464777pln.11 for ; Thu, 30 Nov 2017 07:55:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:subject:from:to:cc:date:in-reply-to:references :mime-version:content-transfer-encoding; bh=jFIWqro604jn2WPYqDIac6fOYG/7t06Ngi4jrIdKfoU=; b=dLHbpNLchHqI9dvxCF9Keyq5gDFKoUHMShN1dBP5R7HmO1oY3MxG3bO5Btn4Kq1ecM TnEABbSLwWEIlaielgd/7jbibsgkhg0o/7tVohJqprkUWY53U0teV3PtKE5umR+69594 DIoelZDyN0LNBSWduJHMycgMn37zr4GjQrQ0xkP2k6j4jD4C+e1BRXCwvn35wdaiEyqT hwMvEcla6urJ1obiM198ohgTttiSNq16WFKcASXpaPThfDuPHswdMYv7sxNHl3Pic7do +b/EN+WgOTddFT3qPe/h5adVkr8faNcbUBwJXThO7qYI4NijoH+xpr7s6FhyE5XR+Fzc xl+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:mime-version:content-transfer-encoding; bh=jFIWqro604jn2WPYqDIac6fOYG/7t06Ngi4jrIdKfoU=; b=l5wxkunyJoiaijVF8vfoHGecBfbEfegme4zL7IKfCa6PazsXhFT7Nn//WWZzaAi9Li TaszzwgD7KZ0ACP5LVqqDOCz1nt4RaCjIYrF+nENKaOfdaUtyDUDcc6GXk5P0QI+NscZ SGaIUzV2p+cUoqkq03moqOAx9LFzQx5kRDDkHdxvQH0BBoIdy2S7nxMYW0St+SB80Ryz NtcMJxHvvBaOoXxlGCTipfO48WxHuVi4p5X8q/dvYBDTsRiW9M6ZxfSBWgOKMhOmI1i2 IoP0J+b6RhEJd4UjULW1E8qU0esUKPj/DrFqlLtn9Uc9vaBCjQsZRcWrmsPh4TK1JpaH up8Q== X-Gm-Message-State: AJaThX7J9XjA0cbhK8mnIJfdPFJV4O5cesjkPIATOuzfI5EceO02ztFa l8Txvot3HabzH9bdWEHhNtQ= X-Google-Smtp-Source: AGs4zMZL2b0RCSCF+N/6ufvH+FsPd/lEQQo1FHUuITdVX4QWf8EBO5k2obbeMUk2v6TYIWjNigUASA== X-Received: by 10.84.212.144 with SMTP id e16mr3190760pli.239.1512057322235; Thu, 30 Nov 2017 07:55:22 -0800 (PST) Received: from [10.1.104.90] ([207.198.105.19]) by smtp.googlemail.com with ESMTPSA id p85sm8213180pfk.147.2017.11.30.07.55.20 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 30 Nov 2017 07:55:21 -0800 (PST) Message-ID: <1512057319.19682.16.camel@gmail.com> From: Eric Dumazet To: Neal Cardwell Cc: Jonathan Morton , Michael Welzl , David Ros , bloat , Yuchung Cheng , Wei Wang Date: Thu, 30 Nov 2017 07:55:19 -0800 In-Reply-To: References: <4D0E907C-E15D-437C-B6F7-FF348346D615@gmx.de> <7B92DF4D-B6B5-4A64-9E10-119DCA2D4A6F@ifi.uio.no> <1512037480.19682.10.camel@gmail.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.6-1+deb9u1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: Re: [Bloat] benefits of ack filtering X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Nov 2017 15:55:23 -0000 On Thu, 2017-11-30 at 09:51 -0500, Neal Cardwell wrote: > On Thu, Nov 30, 2017 at 5:24 AM, Eric Dumazet > wrote: > > I agree that TCP itself should generate ACK smarter, on receivers > > that > > are lacking GRO. (TCP sends at most one ACK per GRO packets, that > > is > > why we did not feel an urgent need for better ACK generation) > > > > It is actually difficult task, because it might need an additional > > timer, and we were reluctant adding extra complexity for that. > > How about just using the existing delayed ACK timer, and just making > the delayed ACK logic a bit smarter? We could try using the existing > logic and timers, but using something adaptive instead of the magic > "2" MSS received to force an ACK. Keep in mind some distros have HZ=250 or even HZ=100 So even a 'one jiffie' timer could add 10ms delay. That is why I believe only a hrtimer could be used (and that would imply CONFIG_HIGH_RES_TIMERS=y ) I am waiting for Anna-Maria Gleixner work (  hrtimer: Provide softirq context hrtimers ) so that we can avoid a trip through a tasklet. >   > > An additional point where huge gains are possible is to add TSO > > autodefer while in recovery. Lacking TSO auto defer explains why > > TCP > > flows enter a degenerated behavior, re-sending 1-MSS packets in > > response to SACK flood. > > Yes, agreed. I suspect there is some simple heuristic that could be > implemented to allow TSO deferral for most packets sent in recovery. > For example, allowing TSO deferral once the number of packet bursts > (TSO skbs) sent in recovery is greater than some threshold. Perhaps > TSO deferral would be fine in Recovery if we have sent, say, 10 skbs, > because at that point if the ACK stream from the original flight > dries up due to massive/tail loss, we have probably sent enough data > in the new flight in Recovery to ensure some kind of ACKs come back > to keep the ACK clock going. > > neal >   > > > > On Thu, 2017-11-30 at 09:48 +0200, Jonathan Morton wrote: > > > I do see your arguments.  Let it be known that I didn't initiate > > the > > > ack-filter in Cake, though it does seem to work quite well. > > > With respect to BBR, I don't think it depends strongly on the > > return > > > rate of acks in themselves, but rather on the rate of sequence > > number > > > advance that they indicate.  For this purpose, having the > > receiver > > > emit sparser but still regularly spaced acks would be better than > > > having some middlebox delete some less-predictable subset of > > them.  > > > So I think BBR could be a good testbed for AckCC implementation, > > > especially as it is inherently paced and thus doesn't suffer from > > > burstiness as a conventional ack-clocked TCP might. > > > The real trouble with AckCC is that it requires implementation on > > the > > > client as well as the server.  That's most likely why Google > > hasn't > > > tried it yet; there are no receivers in the wild that would give > > them > > > valid data on its effectiveness.  Adding support in Linux would > > help > > > here, but aside from Android devices, Linux is only a relatively > > > small proportion of Google's client traffic - and Android devices > > are > > > slow to pick up new kernel features if they can't immediately > > turn it > > > into a consumer-friendly bullet point. > > > Meanwhile we have highly asymmetric last-mile links (10:1 is > > typical, > > > 50:1 is occasionally seen), where a large fraction of upload > > > bandwidth is occupied by acks in order to fully utilise the > > download > > > bandwidth in TCP.  Any concurrent upload flows have to compete > > with > > > that dense ack flow, which in various schemes is unfair to either > > the > > > upload or the download throughput. > > > That is a problem as soon as you have multiple users on the same > > > link, eg. a family household at the weekend.  Thinning out those > > acks > > > in response to uplink congestion is a solution.  Maybe not the > > best > > > possible solution, but a deployable one that works. > > > - Jonathan Morton > > > _______________________________________________ > > > Bloat mailing list > > > Bloat@lists.bufferbloat.net > > > https://lists.bufferbloat.net/listinfo/bloat > > _______________________________________________ > > Bloat mailing list > > Bloat@lists.bufferbloat.net > > https://lists.bufferbloat.net/listinfo/bloat > > > >