From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c: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 EA2403CB35 for ; Sun, 3 Dec 2017 00:20:35 -0500 (EST) Received: by mail-wm0-x229.google.com with SMTP id g130so10412258wme.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=sOGpqlZjrvKJZUnuvvvPYxaklIIclFZ0RPbblyi1f1ndJiYDEn50Nvie3YM67OELKw C3ww6p3xsfl/Tg0ISdQVRG9rRz09HrHMxcn07uNTMJxUwbKIc2kfW69FurA1OlLIBt2b Z/MdiKmd/7i7xJvFdQhTHvCifrbd2gUdCTm/KZ9KqaYLeXjqF8/z8//K8BsXCYNpPeQh MeH4QLErXWhasLIMUo2YdYIZb5DXQaWrfUxtoLI2upiemhy7MUPMj6zNhJRZQP/Lt8nl dcFpQeEyaQiR/+jFjJhuJF/KoiaV9aFUbceW47x05IOVw7H43vqTznA0Xx0z3wvZHwv7 oRcQ== X-Gm-Message-State: AJaThX7rqGI3xTSTFffYip0Be3Zu7VSggoyiD8Cs03p4LaD0g+b50Epd QY/yCkK0218r8ZZn8+9mVbtkIaDzt7WbZcg+M8Vn+w== 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: [Bloat] [Make-wifi-fast] 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: 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--