From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 8831D3B29E for ; Wed, 29 Nov 2017 01:09:19 -0500 (EST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id CE59DB1; Wed, 29 Nov 2017 07:09:17 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1511935757; bh=RoM/XSHedRjhZ3eA+tneyaHwBb1IOzEOG9NXXQ7RoCU=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=WptSMj4sXbMRgX4PQSsr609Mtda9GNKSHTa56HmXcNKX/c0hI/2d9Gjai5Oz0cY8c iBamgtV1k34Jv4Z4B8l9deYHnAl1R1EMsHT2wjw0Mb0LazLXKjvBvA4UBNQ/lY96tO pV5FOYYuSAiWSp+E2D++XmT3uKJtpppBLwgL2zkk= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id CC8C3B0; Wed, 29 Nov 2017 07:09:17 +0100 (CET) Date: Wed, 29 Nov 2017 07:09:17 +0100 (CET) From: Mikael Abrahamsson To: Dave Taht cc: bloat In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed 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: Wed, 29 Nov 2017 06:09:19 -0000 On Tue, 28 Nov 2017, Dave Taht wrote: > Recently Ryan Mounce added ack filtering cabilities to the cake qdisc. > > The benefits were pretty impressive at a 50x1 Down/Up ratio: > > http://blog.cerowrt.org/post/ack_filtering/ > > And quite noticeable at 16x1 ratios as well. > > I'd rather like to have a compelling list of reasons why not to do > this! And ways to do it better, if not. The relevant code is hovering > at: > > https://github.com/dtaht/sch_cake/blob/cobalt/sch_cake.c#L902 Your post is already quite comprehensive when it comes to downsides. The better solution would of course be to have the TCP peeps change the way TCP works so that it sends fewer ACKs. I don't want middle boxes making "smart" decisions when the proper solution is for both end TCP speakers to do less work by sending fewer ACKs. In the TCP implementations I tcpdump regularily, it seems they send one ACK per 2 downstream packets. At 1 gigabit/s that's in the order of 35k pps of ACKs (100 megabyte/s divided by 1440 divided by 2). That's in my opinion completely ludicrous rate of ACKs for no good reason. I don't know what the formula should be, but it sounds like the ACK sending ratio should be influenced by how many in-flight ACKs there might be. Is there any reason to have more than 100 ACKs in flight at any given time? 500? 1000? My DOCSIS connection (inferred through observation) seems to run on 1ms upstream time slots, and my modem will delete contigous ACKs at 16 or 32 ACK intervals, ending up running at typically 1-2 ACKs per 1ms time slot. This cuts down the ACK rate when I do 250 megabit/s downloads from 5-8 megabit/s to 400 kilobit/s of used upstream bw. Since this ACK reduction is done on probably hundreds of millions of fixed-line subscriber lines today, what arguments do designers of TCP have to keep sending one ACK per 2 received TCP packets? -- Mikael Abrahamsson email: swmike@swm.pp.se