Re: [aqm] [tcpm] ACK Suppression
David Lang <david@lang.hm> Tue, 13 October 2015 03:26 UTC
Return-Path: <david@lang.hm>
X-Original-To: aqm@ietfa.amsl.com
Delivered-To: aqm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D93711B2F82 for <aqm@ietfa.amsl.com>; Mon, 12 Oct 2015 20:26:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20nsb_ZePcoq for <aqm@ietfa.amsl.com>; Mon, 12 Oct 2015 20:26:11 -0700 (PDT)
Received: from bifrost.lang.hm (mail.lang.hm [64.81.33.126]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DF1D1B2F75 for <aqm@ietf.org>; Mon, 12 Oct 2015 20:26:11 -0700 (PDT)
Received: from asgard.lang.hm (asgard.lang.hm [10.0.0.100]) by bifrost.lang.hm (8.13.4/8.13.4/Debian-3) with ESMTP id t9D3QAXH021314; Mon, 12 Oct 2015 20:26:10 -0700
Date: Mon, 12 Oct 2015 20:26:09 -0700
From: David Lang <david@lang.hm>
X-X-Sender: dlang@asgard.lang.hm
To: Simon Barber <simon@superduper.net>
In-Reply-To: <561C7314.2030102@superduper.net>
Message-ID: <alpine.DEB.2.02.1510122023250.10958@nftneq.ynat.uz>
References: <mailman.1487.1444233956.7953.aqm@ietf.org> <1444247538.3556484@apps.rackspace.com> <alpine.DEB.2.02.1510072200590.8750@uplift.swm.pp.se> <7A2801D5E40DD64A85E38DF22117852C8812629D@wdc1exchmbxp05.hq.corp.viasat.com> <06C46DC6-854F-4CDE-8C7B-745F3362FA9E@gmail.com> <alpine.DEB.2.02.1510071411400.29851@nftneq.ynat.uz> <E2035448-E688-4EF3-8BF7-02132D72D511@cisco.com> <fa0080678adcd392a8dfa237cbd77e49.squirrel@erg.abdn.ac.uk> <alpine.DEB.2.02.1510082121550.2943@nftneq.ynat.uz> <alpine.DEB.2.02.1510090827240.8750@uplift.swm.pp.se> <561C7314.2030102@superduper.net>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
Archived-At: <http://mailarchive.ietf.org/arch/msg/aqm/YEnSNzClEBHgjW2BcWBjS2pStJU>
Cc: aqm@ietf.org
Subject: Re: [aqm] [tcpm] ACK Suppression
X-BeenThere: aqm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion list for active queue management and flow isolation." <aqm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/aqm>, <mailto:aqm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/aqm/>
List-Post: <mailto:aqm@ietf.org>
List-Help: <mailto:aqm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/aqm>, <mailto:aqm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Oct 2015 03:26:14 -0000
True, assuming that they will all fit in the next burst. but sending all of them lengthens the transmission compared to only sending the minimum, which consumes airtime that that or some other station could be using for data. With congestion of the airwaves such a significant problem, being able to not use some of it is a win overall, even if it doesn't affect a benchmarkk for one station in isolation. David Lang On Mon, 12 Oct 2015, Simon Barber wrote: > The issue here is that the hosts don't know how the medium is going to do the > clumping, so thinning the ACKs at the host may add additional delay. > > From what I understand from Greg's earlier message the cable modem must > request uplink bandwidth in advance, so if it had to send multiple ACKs, it > would send the first one, then request bandwidth the the additional ones that > had arrived since the first one (please correct me if I'm wrong) - in this > case collapsing/thinning the ACKs will reduce latency by one grant cycle. > > WiFi is quite different - there is no need to request bandwidth in advance, > so there is less pressure to collapse the ACKs - just send them all and they > will be burst out when the medium becomes available. > > Simon > > On 10/8/2015 11:43 PM, Mikael Abrahamsson wrote: >> On Thu, 8 Oct 2015, David Lang wrote: >> >>> Ok, so it turns out that what we are talking about here is talked about >>> explicitly in section 5.2.1 of RFC3449. It warns of increased sender burst >>> sizes, but I really question if that's a valid concern in the cases that >>> we are talking about here. The choice in these cases isn't to send more >>> acks spaced out, but rather to send a lot of acks back to back in one >>> transmit slot vs one stretch ack per transmit slot. >> >> Exactly. And in my specific case, we're talking 20kPPS of data down, and >> 10kPPS of ACKs, over a medium that allows the modem to send a bunch of >> packets only once every few milliseconds. >> >> So there are two alternatives: >> >> You get approx 10-60 ACKs as a "train of ACKs" within 0.3 milliseconds, >> every 1-4 milliseconds. >> >> You get 1-3 ACKs within 0.1ms, every 2-3 milliseconds. These ACKs will >> acknowledge 16-32 packets at a time. >> >> By the nature of the beast, I'd say that this kind of medium implicitly >> will be able to handle the "bursts" we're talking about here, if you ACK >> 24-48kilobyte of data per ACK (when a middle box does ACK Suppression to >> remove intermediate ACKs), it's implicit that the medium designers know >> that they can handle a wirespeed burst of data that is the result of the >> ACKing of these fairly large number of bytes. >> >> But again, I question the wisdom in ACKing every 2 packets when the >> congestion window is in the hundreds of kilobytes and you're sending tens >> of thousands of packets per second. >> >> I suggested in another part of the thread that perhaps the host itself >> should do ACK suppression and don't send ACKs more closely together than >> once per millisecond or 1/10th RTT, whatever is lower. Perhaps the RTT >> value needs to be even lower, 1/25 of RTT or something. >> >> In my specific test, using once per millisecond or 1/25 of RTT would cut >> down the number of ACKs to around 2kpps instead of the 10kpps ACKs I see >> now, but it wouldn't cut it down to the around 500-1000 ACKs per second >> that the DOCSIS modem is cutting it down to... >> >> I think that as bandwidths go up, there are changes to TCP that can be done >> to make it work better, and reducing the frequency of ACKs sent depending >> on RTT and different window sizes might be a way forward. I fully believe >> there are cases where ACKing every 2 packets is exactly the right way to >> go, but when you're sending 1 gigabit/s over 100ms RTT and the medium >> itself clumps the packets together because that's what it does, then these >> ACKs don't carry the same information anymore and some of them could be >> optimized away (preferrably by the host stack) to spare upstream bandwidth >> and transmit opportunities. >> > > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm >
- Re: [aqm] ACK Suppression dpreed
- Re: [aqm] ACK Suppression Mikael Abrahamsson
- Re: [aqm] ACK Suppression Agarwal, Anil
- Re: [aqm] ACK Suppression Jonathan Morton
- Re: [aqm] ACK Suppression dpreed
- Re: [aqm] ACK Suppression dpreed
- Re: [aqm] ACK Suppression dpreed
- Re: [aqm] ACK Suppression Christian Huitema
- Re: [aqm] ACK Suppression David Lang
- Re: [aqm] ACK Suppression David Lang
- Re: [aqm] ACK Suppression David Lang
- Re: [aqm] ACK Suppression Greg White
- Re: [aqm] ACK Suppression Jana Iyengar
- Re: [aqm] ACK Suppression Scharf, Michael (Michael)
- Re: [aqm] ACK Suppression Bless, Roland (TM)
- Re: [aqm] ACK Suppression Fred Baker (fred)
- Re: [aqm] ACK Suppression David Lang
- Re: [aqm] ACK Suppression Fred Baker (fred)
- Re: [aqm] ACK Suppression David Lang
- Re: [aqm] ACK Suppression Joe Touch
- Re: [aqm] [tcpm] ACK Suppression gorry
- Re: [aqm] [tcpm] ACK Suppression David Lang
- Re: [aqm] [tcpm] ACK Suppression Mikael Abrahamsson
- Re: [aqm] ACK Suppression Greg White
- Re: [aqm] ACK Suppression Jonathan Morton
- Re: [aqm] ACK Suppression Jana Iyengar
- Re: [aqm] [tcpm] ACK Suppression Simon Barber
- Re: [aqm] ACK Suppression Simon Barber
- Re: [aqm] [tcpm] ACK Suppression David Lang
- Re: [aqm] ACK Suppression Bless, Roland (TM)
- Re: [aqm] [tcpm] ACK Suppression Greg White
- Re: [aqm] ACK Suppression dpreed
- Re: [aqm] ACK Suppression Jonathan Morton