From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (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 CC8403BA8E for ; Mon, 11 Dec 2017 15:15:54 -0500 (EST) Received: by mail-lf0-x236.google.com with SMTP id i2so20618828lfe.9 for ; Mon, 11 Dec 2017 12:15:54 -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; bh=pgE/YtXIxH2wd4NaOG6d52ZqVyVO6GPxUzY3TwvLT4k=; b=KqGDLp1yOSyV/BBvGQ6bIBVGPCFM7RObN/SHLJJ1WTyJ/FyJuV3AZdbNnYOJ55zoiX JkcOVguAMrhOSCHKVbCzKpgA+eR/ozYMsKIIvCUwCgUvGoSqI+PxXBN97PLmtOHNYJ/f cA5BSfWyr5zrcLJHq7sjRHan+N5Hi3MXDeLPcfiCo3u105nmzPjtzioBELt5mCeZ6Ei9 WL+/ldC1selOvQyLQWRAZ2S/iEzzLmbmgZeq70seV98vf9bi1s+nM2+COM/RNnd7q4fS NjLdOitVCJM8vcy2aaVAtv7H76W9/2o1UQ2UFxTUDkcoEa3LVjhXfiUD9GGz/UwZjFvv vxEA== 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; bh=pgE/YtXIxH2wd4NaOG6d52ZqVyVO6GPxUzY3TwvLT4k=; b=kd78RXH1oo+/WBTLNClETRpe/rFDWLbaI/eFh85zrUKe3G4qyDpYlqjcg/VvietJwv dyMc6i5/QplTHlzpotHoByoIsIoqXnOo8J8FEawMA8hv3ZeMy7SkhTwGDXOZjYyyOqmz 6NF6Jw7Pe5qLuJcfl7uTEy3pdDd5S3ERxWs92BOK+f2Thyj7uA7QWUO3rzHd65qJJob+ yxSldN4NsVZbJBfnQVuB5UJ8PbisVJbvXETY9WtMWVbxHSBE55qO6X+FjrEkdl+48GB2 KTX/WkTgVy0ZM4MbQfVs6jOeqvJwu6tLD9nbktRdwPFJ60hqEgTfLLXgTQKAPqrHo8tf sC5Q== X-Gm-Message-State: AKGB3mJapKTlPdYkUe4F+U2Joziad+JRpIEZrBUIx74W9JDtav52lJat o0guIOuk7SI9aB/iiCnPiLXoVtbDKx1eoZVKqRA= X-Google-Smtp-Source: ACJfBouLfY2TSGNktbFZT9E+MlEEwSwdnzSjE3bkgR2qsqSgh/pgRM8orcyqV7pMjtOdrKxXkxNAtOJoI4Q/QIBWIVY= X-Received: by 10.46.87.77 with SMTP id r13mr778864ljd.128.1513023353558; Mon, 11 Dec 2017 12:15:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.17.202 with HTTP; Mon, 11 Dec 2017 12:15:51 -0800 (PST) In-Reply-To: References: From: Benjamin Cronce Date: Mon, 11 Dec 2017 14:15:51 -0600 Message-ID: To: Mikael Abrahamsson Cc: Dave Taht , bloat Content-Type: multipart/alternative; boundary="f403045f870c869d560560163313" 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: Mon, 11 Dec 2017 20:15:55 -0000 --f403045f870c869d560560163313 Content-Type: text/plain; charset="UTF-8" I wonder if TCP could be effectively changed to send an ACK every WindowSize/N number of packets. We'd need to be careful about how this would affect 'slow start'. On Wed, Nov 29, 2017 at 12:09 AM, Mikael Abrahamsson wrote: > 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 > > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat > --f403045f870c869d560560163313 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I wonder if TCP could be effectively changed to send an AC= K every WindowSize/N number of packets. We'd need to be careful about h= ow this would affect 'slow start'.
=
On Wed, Nov 29, 2017 at 12:09 AM, Mikael Abr= ahamsson <swmike@swm.pp.se> wrote:
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 makin= g "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.<= br>
At 1 gigabit/s that's in the order of 35k pps of ACKs (100 megabyte/s d= ivided 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 sen= ding 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 ups= tream time slots, and my modem will delete contigous ACKs at 16 or 32 ACK i= ntervals, ending up running at typically 1-2 ACKs per 1ms time slot. This c= uts 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 kee= p sending one ACK per 2 received TCP packets?

--
Mikael Abrahamsson=C2=A0 =C2=A0 email: swmike@swm.pp.se
<= div class=3D"h5">
_______________________________________________
Bloat mailing list
Bloat@list= s.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

--f403045f870c869d560560163313--