From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (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 723E23BA8E for ; Thu, 30 Nov 2017 02:45:13 -0500 (EST) Received: by mail-qt0-x235.google.com with SMTP id d4so7669423qtj.5 for ; Wed, 29 Nov 2017 23:45:13 -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=9UCdrQIgnvDuay4GTXNejypaq1lKGQpxLJj7swtkoG0=; b=Jz/kr30il2zHVgSenCRpfpebdtNXs4J+wXHtDcBdOXjlA+pkwuFS4wrS0C7BcawGjT cplyI68t1ySiq5kZ+aPKgbqHHx2kY8WEPro4w+NrDBtzZF4KNkUC69glXKJPpzgcCVZH P4QOLJCTzkifb52GE1nqU3clSD/uDoYVqXBXLr/B3ZjAqtRTord9zfGLpRfMZHO4mqEy lJT41RnHjTujuheQTKcrUDVMYqKebl11DMbAhqG8cEgPgiA3oPjkdIqB/cj2SN7zkuUD 0lMFgLS4WDPtx/ovcuwS3oasRtzIhDi9ogwvPoYSszJODeqR5wWXvgwAtJ5kZeGIzpvj WRpA== 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=9UCdrQIgnvDuay4GTXNejypaq1lKGQpxLJj7swtkoG0=; b=UoWnz3swq+YS+5rCTL8jgExoIGegoXxYDqZ+MmxtsEmE4khZJtRoClXYRlaoynhE9o R6PJP1FaQbcUJMsH/jlIddHZLeAIJcg7YsEtJ/21LaMAXaHXJ4EDwXRnFwvGe+EVK56/ Og9utEug/k1H/D9dm2H/wIs8kZRFSUmK0syQxc0OXadFMUK+GpivZyac25CK+wBseOqb sfv66MJx8tGEfhpvIRfOkdeUG2BDSYTBQvfRe0nOvPSrskmTjAUuBUCBQvrDCnCJZAmC mGMzfo55VQuCfRxg5D9bEpcGOXWqvA2qyri3kEqyCTSz9evK3rVggZWjQ7IFMsWa+OVi xYQg== X-Gm-Message-State: AKGB3mIBqOSbpVdwbuK6TjHX2SvrQZwlWVdiAhMREG8gDEVhtC3Um/+f 2lGguKWojUUHllyITNo8dgY1lTCBnqY9Hyf1zHk= X-Google-Smtp-Source: AGs4zMYOduulobVsL8SVC0bW187VR6oPVXC9LLA7A8Eqqw2vfveVg3Zfhm2YmCYC2brqWRrF5QhpOR9uTCnhxksESDA= X-Received: by 10.200.48.51 with SMTP id f48mr2164367qte.262.1512027912907; Wed, 29 Nov 2017 23:45:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.193.93 with HTTP; Wed, 29 Nov 2017 23:45:12 -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:45:12 -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:45:13 -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, Nor one Linux. >2) ACKs are still quite > important in Fast Recovery, If you are already achieving twice the rate, what does occasionally losing fast recovery cost? >3) BBR might not need to clock out ACKs, but it > measures their incoming rate. if it collapses to a punctuated paced source, it could also notice acks being lost, and extrapolate. > 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. I'm not a huge fan of slow start in IW10. And: Strike "unnecessarily is", and substitute "may not be", as http://blog.cerowrt.org/flent/ack_filter/1Gbit-20Mbit-rrul_be.png seems to show. The ack-filter result shows one flow growing rapidly, and three others not. > 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