From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.taht.net (mail.taht.net [176.58.107.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 490F33B29E for ; Fri, 1 Dec 2017 13:43:25 -0500 (EST) Received: from nemesis.taht.net (unknown [IPv6:2603:3024:1536:86f0:2e0:4cff:fec1:1206]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.taht.net (Postfix) with ESMTPSA id E12C621367; Fri, 1 Dec 2017 18:43:23 +0000 (UTC) From: Dave Taht To: Luca Muscariello Cc: Sebastian Moeller , bloat References: <4D0E907C-E15D-437C-B6F7-FF348346D615@gmx.de> <7B92DF4D-B6B5-4A64-9E10-119DCA2D4A6F@ifi.uio.no> <1512037480.19682.10.camel@gmail.com> <401BE104-CFCC-449C-9904-A7C118B869E2@gmx.de> Date: Fri, 01 Dec 2017 10:43:22 -0800 In-Reply-To: (Luca Muscariello's message of "Fri, 1 Dec 2017 11:45:19 +0100") Message-ID: <874lpagugl.fsf@nemesis.taht.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain 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: Fri, 01 Dec 2017 18:43:25 -0000 Luca Muscariello writes: > For highly asymmetric links, but also shared media like wifi, QUIC might be a > better playground for optimisations. > Not pervasive as TCP though and maybe off topic in this thread. I happen to really like QUIC, but a netperf-style tool did not exist for it when I last looked, last year. Also getting to emulating DASH traffic is on my list. > > If the downlink is what one want to optimise, using FEC in the downstream, in > conjunction with flow control could be very effective. > No need to send ACK frequently and having something like FQ_codel in the > downstream would avoid fairness problems that might > happen though. I don't know if FEC is still in QUIC and used. > > BTW, for wifi, the ACK stream can be compressed in aggregate of frames and sent > in bursts. This is similar to DOCSIS upstream. > I wonder if this is a phenomenon that is visible in recent WiFi or just > negligible. My guess is meraki deployed something and I think they are in in the top 5 in the enterprise market. I see ubnt added airtime fairness (of some sort), recently. > > On Fri, Dec 1, 2017 at 9:45 AM, Sebastian Moeller wrote: > > Hi All, > > you do realize that the worst case is going to stay at 35KPPS? If we assume > simply that the 100Mbps download rate is not created by a single flow but by > many flows (say 70K flows) the discussed ACK frequency reduction schemes > will not work that well. So ACK thinning is a nice optimization, but will > not help the fact that some ISPs/link technologies simply are asymmetric and > the user will suffer under some traffic conditions. Now the 70K flow example > is too extreme, but the fact is at hight flow number with sparse flows (so > fewer ACKs per flow in the queue and fewer ACKs per flow reaching the end > NIC in a GRO-collection interval (I naively assume there is a somewhat fixed > but small interval in which packets of the same flow are collected for GRO)) > there will be problems. (Again, I am all for allowing the end user to > configure ACK filtering thinning, but I would rather see ISPs sell less > imbalanced links ;) ) > > Best Regards > Sebastian > > > > > On Dec 1, 2017, at 01:28, David Lang wrote: > > > > 35K PPS of acks is insane, one ack every ms is FAR more than enough to do > 'fast recovery', and outside the datacenter, one ack per 10ms is probably > more than enough. > > > > Assuming something that's not too assymetric, thinning out the acks may > not make any difference in the transfer rate of a single data flow in one > direction, but if you step back and realize that there may be a need to > transfer data in the other direction, things change here. > > > > If you have a fully symmetrical link, and are maxing it out in both > direction, going from 35K PPs of aks competing with data packets and gonig > down to 1k PPS or 100 PPS (or 10 PPS) would result in a noticable > improvement in the flow that the acks are competing against. > > > > Stop thinking in terms of single-flow benchmarks and near idle 'upstream' > paths. > > > > David Lang > > _______________________________________________ > > Bloat mailing list > > Bloat@lists.bufferbloat.net > > https://lists.bufferbloat.net/listinfo/bloat > > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat > > > > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat