From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (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 A37123B29E for ; Fri, 1 Dec 2017 14:36:13 -0500 (EST) Received: by mail-qk0-x229.google.com with SMTP id a71so14532020qkc.9 for ; Fri, 01 Dec 2017 11:36: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=kyW+/7YP0rgkynjW08uIFiB1wqowN7QHHbvQhioCyXo=; b=Ue2EN+vJgJPrx/UgQhjCq1H0lgTnlVed8d8FZH8G6838aD7UwBDyEW2DuvpZfvmqzx 9jB3J3hyBzckGQ0Qo6r2ZZ5q7/sOOKsV4PpsS5ntFRFhNn1ihD152zk8EQL1/UOCDsOx AlxPz1yKgUMQLEPSAj6HijN9BpOoVtUL21syrZQfNGqU8x4cgB8z/mQMBdlCF/WU1yB1 Tn7iR3Hyk5xCueYrJLg23uDeG3B8GPP1lQzqWGqhxAEcJtS7NHRC/7g/1Xl8fgRnVFjr Jfvy+mXplKhIz2rl86mPAR3bxMTD9+U5zwt+JUUEmlMyUEDNOTuxmgFd2dBOQgHG26f4 HrJQ== 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=kyW+/7YP0rgkynjW08uIFiB1wqowN7QHHbvQhioCyXo=; b=RGbPW1NSSKYTb10d3+itPn2iEehyw9zDAfh9JMAVGeQ7eEZ2y1l5gR2ZB8Vsj3PBc7 XCsP+oFNRln2AllxYhxNupPCO7u9sSwmvBAwZdDrAevN/r2mvAtaRs18g7sciQCVTwz9 /8HkEoc80roXGjknVOUEah68aoz8D1/gUOTixJhVV4jPegbqnhNzY6ZXnbSGXXgWnfzy jlmpuNmicwVpaYoNwn57GctyDEpEkVRthhMylLWoA3Yj0mbtjEmNFCVanFMAdbIEpqva 0wA+RnlRJ1gp5WwRyrDeYASZLGAwYprp/ehXuZumDr479RyGVd7VdXgk90karyB7Q8Fs S9hA== X-Gm-Message-State: AKGB3mLEnPEL+KlOeSKIAzK7LfDMPoB53nqEPyOO595si/3RQoE7bH1G 9qXqpqaRw775Gp0rJo4Ezpk7getdHNgbCO5NhJc= X-Google-Smtp-Source: AGs4zMaHFRRJtjpRgFjr4P2gZ13gBEXdGzDbt8Yt04hgxiwCaFL3qGXVwAuj3pVX/C17D39Xi870X2JQWFfROEIxZoo= X-Received: by 10.55.201.155 with SMTP id m27mr9272887qkl.299.1512156973111; Fri, 01 Dec 2017 11:36:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.193.93 with HTTP; Fri, 1 Dec 2017 11:36:12 -0800 (PST) In-Reply-To: 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> <874lpagugl.fsf@nemesis.taht.net> From: Dave Taht Date: Fri, 1 Dec 2017 11:36:12 -0800 Message-ID: To: Luca Muscariello Cc: Dave Taht , bloat 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: Fri, 01 Dec 2017 19:36:13 -0000 On Fri, Dec 1, 2017 at 10:57 AM, Luca Muscariello wrote: > https://www.cisco.com/c/en/us/products/collateral/wireless/aironet-3700-s= eries/white-paper-c11-735947.html > Good news all over. I wonder what happens on cisco against the suite of tests toke made available here: https://www.cs.kau.se/tohojo/airtime-fairness/ People are getting some good results with this stuff: https://forum.lede-project.org/t/ubiquiti-unifi-ac-mesh/4499/4 (however, I currently have 6 bricked ones that I need to recover, and am having way more fun in simulation that I imagined I could ever have).... > On Fri 1 Dec 2017 at 19:43, Dave Taht wrote: >> >> Luca Muscariello writes: >> >> > For highly asymmetric links, but also shared media like wifi, QUIC mig= ht >> > 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 t= he >> > 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 jus= t >> > 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, b= ut >> > 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 fl= ow >> > 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 ne= ed >> > 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 a= nd >> > 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 > > > _______________________________________________ > 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