From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (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 11D1E3BA8E for ; Thu, 30 Nov 2017 02:24:28 -0500 (EST) Received: by mail-qt0-x233.google.com with SMTP id d15so7622016qte.4 for ; Wed, 29 Nov 2017 23:24:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=DLxNocnESkVTKkI+WgW+gPIcjFP+LZ3GWYbdNAFrcII=; b=KO9QGJdCnalvoPulT5XTCwlbJXD2+27i4KmvF4F+7VNRt5zNyWcA+ZIJEv6guaeKX7 WB7xvJA1QDoAmU2lwnx7wYNfMTRwrRkhK4lActcTWpXusdTP3uOiR1H/BS+JRSunyNR9 8NIiwDduOgIN4BZNCIUtuAntGUD9CsQnZjB3lMBaXGy/ns3B6xxurkyWgWGk8Q+EtZN6 EpyemhRtTU37qb4VxTi6KVRc1LHQolIPZg5QCUWzOgUfW3MNaToNNVa+0plu2PguiRxP 0PnmsE7ebzoD7mysI/3XR+SzT7kqmwPMEWg0fb5xZbnBnoMtA725Tz8B1OkUooa1N7lX EeWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=DLxNocnESkVTKkI+WgW+gPIcjFP+LZ3GWYbdNAFrcII=; b=ngwU3WSJFvNnQUtSjQB/D0lCQBFryZ5xLj/VaCXV74RCfjm81LNSvpKiqhU6ZFALl9 wMaxFYPcln5w3eejztTabZa4gUEbykbja4DkutqkGeNYj3S4f1F+qiPTDNQi/5tQM3PP D1UmkQZPigiOqakEr4YKiITIPGQD+wv7MxALGgw5moQ4Oc7wP4lvXolPJmtWRc7hC+WR 18XpN2sTp9y2+MImBY4BIMe0PxoQIPI9TPZZgUUHEYwgD06nxT9yoyRo4AvglC8JNhU/ scpcP+fp/M04Y0qZdD2L4rzNdm6RXSzda/MtQ3cmvMUMAE/RQSJi71oDzx3O/lHLCvUc hunA== X-Gm-Message-State: AKGB3mJXXKybRgcZ6B1qeO/XR8Q97AYp5qB1+KVPiwQGjLlU2+KOMN1c X8IAuhtgFYfvrB+qaVndTpcZZFI6yANz4a/uInc= X-Google-Smtp-Source: AGs4zMb+0xTK/gkC4q9RuMZYQ91ipAQkCGxOAmxdI6QGzDCoeHT64rwbvl0ONLkj4fkynV0RK1AiUJBApx5zrhDSBIo= X-Received: by 10.200.36.203 with SMTP id t11mr2161938qtt.277.1512026668523; Wed, 29 Nov 2017 23:24:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.193.93 with HTTP; Wed, 29 Nov 2017 23:24:27 -0800 (PST) In-Reply-To: <7B92DF4D-B6B5-4A64-9E10-119DCA2D4A6F@ifi.uio.no> References: <4D0E907C-E15D-437C-B6F7-FF348346D615@gmx.de> <7B92DF4D-B6B5-4A64-9E10-119DCA2D4A6F@ifi.uio.no> From: Dave Taht Date: Wed, 29 Nov 2017 23:24:27 -0800 Message-ID: To: Michael Welzl Cc: bloat , David Ros Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 07:24:29 -0000 On Wed, Nov 29, 2017 at 11:03 PM, Michael Welzl wrote: > Hi Bloaters, > > I=E2=80=99d like to give offer some information and thoughts on AckCC, at= the bottom > of this email. > > > On Nov 29, 2017, at 4:53 PM, Luca Muscariello > wrote: > > > > On Wed, Nov 29, 2017 at 3:31 PM, Mikael Abrahamsson > wrote: >> >> On Wed, 29 Nov 2017, Luca Muscariello wrote: >> >>>> Why does it say to do this? What benefit is there to either end system >>>> to >>>> send 35kPPS of ACKs in order to facilitate a 100 megabyte/s of TCP >>>> transfer? >>> >>> >>> Did you check RFC 3449 ? >>> https://tools.ietf.org/html/rfc3449#section-5.2.1 >> >> >> RFC3449 is all about middleboxes doing things. >> >> I wanted to understand why TCP implementations find it necessary to send >> one ACK per 2xMSS at really high PPS. Especially when NIC offloads and >> middleboxes frequently strip out this information anyway so it never rea= ches >> the IP stack (right?). >> > > I would say because it is complex to guess at which PPS to work. You woul= d > need an adaptation mechanism. Need also to change the client and the serv= er > sides. The AckCC Jonathan has mentioned > might be a solution to that. > Probably an ACK pacer in the end host, out of the TCP stack, doing Ack > filtering and decimation can be simpler to implement than the proper > adaptation mechanism in TCP. > Maybe inside sch_fq it would be doable. Maybe not. > > > I=E2=80=99m adding the response from Jonathan Morton here to make this mo= re > self-contained: > *** > Given an RTT estimate and knowledge of the congestion window, the AckCC > option could be used to target a handful of acks (maybe 4 to 10) per RTT. > As usual, extra acks would be sent when loss is suspected, on ECN events, > and when the push flag is set. > > That would be perfectly sufficient. > > - Jonathan Morton > > *** > > A few years ago, David Ros, whom I=E2=80=99m adding in cc, one of the ori= ginal > authors of RFC 5690 did a sabbatical with me at the University of Oslo. A= s > part of that, we advised a master student to carry out tests with AckCC, = and > analyze the RFC to understand how it would have to change if we were to > proceed to Proposed Standard. The result of his investigation is here: > http://heim.ifi.uio.no/michawe/teaching/dipls/marius-olsen/mastersthesis-= mariusno.pdf > and his code is here: http://folk.uio.no/mariusno/master/ > > Now, after finishing the thesis, when it came to writing a paper about it= , > we got stuck in the discussion of =E2=80=9Chow are we going to explain th= at this is > really necessary?=E2=80=9D > - we didn=E2=80=99t want to submit a =E2=80=9Csolution searching for a pr= oblem=E2=80=9D paper and > didn=E2=80=99t want to get rejected for not having shown that the problem= truly > exists. Searching for this a little in the academic world (papers) gave u= s > no result, at least back then. > > Interestingly, at IETF 98, not so long ago, Ingemar Johansson explained t= o > folks at TSVWG that the problem IS real: > https://datatracker.ietf.org/meeting/98/materials/slides-98-tsvwg-sessb-7= -transport-protocol-feedback-overhead-issues-and-solutions/ > > So, let me now try to answer =E2=80=9Cwhy is TCP not doing that?=E2=80=9D= . > - First, AFAIK, AckCC isn=E2=80=99t implemented anywhere (except that we= have this > old patch - please feel free to download, adapt, and play with it !!) > - Second, if someone was to update TCP to support this, a bit more than > simple statements about the amount of traffic being large would be good I= MO > - I mean, some convincing proof that the large number of ACKs *really* is= a > problem. > - Third, once this is implemented and deployed and found to be beneficial= , > it would be useful to follow up in the IETF and update RFC 5690. > > Since nobody seems to be doing any of these things, nothing changes. But > consider this: I see folks from Google doing a lot of TCP updates in the > IETF for which they themselves appear to have an immediate need. Given th= e > heterogeneity and magnitude of traffic produced by Google, if they don=E2= =80=99t see > a pressing need for it, I suspect that, indeed, the problem might not be = so > real after all?! > > Also, a word of caution. In this thread, there seems to be general agreem= ent > that TCP sends way too many ACKs, and that reducing that number would be > fantastic. > I=E2=80=99m not so convinced. Okay, even if TCP isn=E2=80=99t that ACK-cl= ocked anymore in > Linux: 1) there isn=E2=80=99t only Linux in this world, 2) ACKs are still= quite > important in Fast Recovery, 3) BBR might not need to clock out ACKs, but = it > measures their incoming rate. For another example, consider a non-BBR > sender in slow start: without ABC, missing ACKs would let it grow its cwn= d > too cautiously. Thanks to ABC, this can be done more aggressively - but A= BC > recommends a limit on how quickly to =E2=80=9Cjump=E2=80=9D in the rate i= n response to a > single ACK, for good reason - to avoid producing even heavier bursts. But > with this limit, again, the TCP sender is unnecessarily cautious in Slow > Start just because it misses ACKs. My answer to questions like this that are difficult reason about... is to run the experiment. Trying out BBR in the testbeds we have setup would be straightforward, although rrul_be (which is what we have the MOS results for) is not the best test for BBR's behaviors. Maybe more of a staircase test would be better. (note we're also looking at sfq and pfifo as references) > My point is: the ACKs ARE the feedback that TCP works on; when you take t= hem > away, TCP becomes =E2=80=9Cblind=E2=80=9D, and whatever improvement is ma= de to TCP will have > to be developed on that basis. > > I=E2=80=99m not saying that 1 ACK for every two packets is really necessa= ry=E2=80=A6 but > unless there=E2=80=99s hard proof that this really is a problem, I=E2=80= =99d caution against > a =E2=80=9Cdownward spiral=E2=80=9D here: the level of asymmetry offered = to users today is > probably somehow related to the commonly seen TCP ACK rate - so if TCP > starts to reduce the ACK rate, folks may decide to make links even more > asymmetric, etc. etc. =E2=80=A6 I=E2=80=99m not sure this is a good direc= tion. > > Just some thoughts, and some context. > > Cheers, > Michael > > > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat > --=20 Dave T=C3=A4ht CEO, TekLibre, LLC http://www.teklibre.com Tel: 1-669-226-2619