From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (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 DD4A23BA8E for ; Sun, 3 Dec 2017 00:20:35 -0500 (EST) Received: by mail-wm0-x22a.google.com with SMTP id g130so10412257wme.0 for ; Sat, 02 Dec 2017 21:20:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XEHMPs2aOqpcoqJr7hWcOHOE4u80QzxC8mR+pGI3ffo=; b=FvXP4vWwn+SPAklea1E1Z5/EdK5cDZoZEJ1bsMzVsurzU6yE2ccEB5/sq6lZOnwbpq 5SmuAteiCH6tgQI9V3ImE5ixQQQj4gzVW0jLhpm6g0NeFwf4YRvcNFi/Gh3T4S3udgSI ilmxlzK+0phKAlhfBELBj5N5KKn1MDO6wvEwQ= 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=XEHMPs2aOqpcoqJr7hWcOHOE4u80QzxC8mR+pGI3ffo=; b=TFegC3reZuswTSZfUUDgCibuYN8Nb64KcwgaKgX7m311xolH0XE/fYC6BLbU0BCrkB 5rd3uFjD3e17XtuCWG5xEXTw37Dphe4j65jAnOYycEIX6JAScYJG88veVJkU9TutoIm0 ZNIC8BSn87CCKycU7y4JV4fRGrcY3hKF91WgxXYf2XnRWDAOv61zPZyZ6PrS71LrwI6l EIuK37Rm1rnEwTfPat4VJ+DhtY8fFCrrWeGUXvEsqDFp21dW+a+CezT3xoPcSGLnjMNH fwPhpX49N2870Vn7CqR5VU3PpjsDsKSRQ3fSZ6E53wttr3FZiami42VKId5R5UNZcRDY b2Rw== X-Gm-Message-State: AJaThX7UFcfI4GIF5MLRUriEE8ZaklDnvhPO4hcgoe5J/5py4gdjml7G 87/97jDooJYt5nS5HNnkHDs1aznmDUNmTJHS9Eaf7g== X-Google-Smtp-Source: AGs4zMYISzDYKnOrpn8cpweDZE8gAvA0Cu21pTmY7V7IdM5K7bFD9asSHU9tpzznsjdciNY06Ib/ntqFHEPP64GfZOY= X-Received: by 10.80.212.158 with SMTP id s30mr25387826edi.286.1512278434331; Sat, 02 Dec 2017 21:20:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.195.196 with HTTP; Sat, 2 Dec 2017 21:20:33 -0800 (PST) In-Reply-To: <87shcui3ni.wl-jch@irif.fr> References: <4D0E907C-E15D-437C-B6F7-FF348346D615@gmx.de> <7B92DF4D-B6B5-4A64-9E10-119DCA2D4A6F@ifi.uio.no> <1512037480.19682.10.camel@gmail.com> <6b494910-1373-afb0-5b93-99b725391fb3@gmail.com> <87wp2638yo.fsf@toke.dk> <87tvxa36sn.fsf@toke.dk> <87po7ygxai.fsf@nemesis.taht.net> <87shcui3ni.wl-jch@irif.fr> From: Bob McMahon Date: Sat, 2 Dec 2017 21:20:33 -0800 Message-ID: To: Juliusz Chroboczek Cc: Dave Taht , make-wifi-fast@lists.bufferbloat.net, bloat Content-Type: multipart/alternative; boundary="94eb2c1affd0e17327055f68c240" Subject: Re: [Make-wifi-fast] [Bloat] benefits of ack filtering X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Dec 2017 05:20:36 -0000 --94eb2c1affd0e17327055f68c240 Content-Type: text/plain; charset="UTF-8" I'm skeptical that this would improve single stream throughput by a factor of two. The larger RTT would drive larger aggregations and it's aggregation that scales peak average throughput. Also, the time difference between the 802.11 ack and the client network stack writing the TCP ack would probably be in the 100s of microseconds (mileage will vary.) So it's the client's media access that will drive the increase in RTT. It might be preferred to modify EDCA parameters to reduce media access latencies for TCP acks rather than spoof them. Bob On Fri, Dec 1, 2017 at 12:39 PM, Juliusz Chroboczek wrote: > >> It does increase single-flow TCP throughput by up to a factor of two, > >> though... Which everyone knows is the most important benchmark number ;) > > > Were you always as cynical as I am? > > (Giggle) > > Dave, you've always underestimated Toke ;-) > _______________________________________________ > Make-wifi-fast mailing list > Make-wifi-fast@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/make-wifi-fast > --94eb2c1affd0e17327055f68c240 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm skeptical that this would improve single stream th= roughput by a factor of two.=C2=A0 =C2=A0The larger RTT would drive larger = aggregations and it's aggregation that scales peak average throughput.= =C2=A0

Also, the time difference between the 802.11 ack and the clie= nt network stack writing the TCP ack would probably be in the 100s of micro= seconds (mileage will vary.)=C2=A0 So it's the client's media acces= s that will drive the increase in RTT.=C2=A0 =C2=A0 It might be preferred t= o modify EDCA parameters to reduce media access latencies for TCP acks rath= er than spoof them.=C2=A0

Bob

On Fri, Dec 1, 2017 at 12:39 PM, Juliusz Chrobocze= k <jc= h@irif.fr> wrote:
>> It does increase single-flow TCP throughput by up to a fa= ctor of two,
>> though... Which everyone knows is the most important benchmark num= ber ;)

> Were you always as cynical as I am?

(Giggle)

Dave, you've always underestimated Toke ;-)
______________________________= _________________
Make-wifi-fast mailing list
Make-wifi-fast@list= s.bufferbloat.net
https://lists.bufferbloat.net/listinfo/mak= e-wifi-fast

--94eb2c1affd0e17327055f68c240--