From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (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 8B6A13B29E for ; Fri, 1 Dec 2017 16:18:01 -0500 (EST) Received: by mail-wm0-x236.google.com with SMTP id l141so5789919wmg.1 for ; Fri, 01 Dec 2017 13:18:01 -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=vXoG0vJw7zNRnQkmi+k7Krw2sF/RloDp+821P/7wlFM=; b=AIi6tQ/YXsedPZYZLgTpR5pGeNti5JUcUSyV5qEsP9u6Zee7roK3ZyZhzpXo0V/IL6 2VvJiyb/3HMDFEo2Eb7tf1tH0Bp9IeJtPawf6MVCK72Sm+Wg0WOgEVsQVtNkTZ0QSm9L hqax3WWZ+xctxX0+ZQL80NplKZ3vL8XeSiRsE= 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=vXoG0vJw7zNRnQkmi+k7Krw2sF/RloDp+821P/7wlFM=; b=RkFb3V53zSDdueOtuUr/LI8KmQYHGnwLV3FnKHc1Gww8nDBsVbZkS3Aauz/CTB5n1s 5KCUo5VIg45w+B9dta6vutjHcyF2sk967ky1TEqErDhA5o0/rU/leQX7BTTIZCnELefs HLNGhk78NVSzGnWZr+JIcN8r9zu92xUJpVvGSKMikeCanFUUpRnMqn+/eRw2YE7gbLjP b7bzWFN0xKqlJD3Wdg94ox/UZlqdndkT/P8quVw23X0U0wSmQrXyy+7f85TygTBgsjxg noJiUyjV9bNOsema+/fjzKMXdPx545VsjFLHi1ieAV8G/om/x3t4AigWgxoe5RI6CSZf PN4A== X-Gm-Message-State: AJaThX6NuTsnaIojf5VKBxsdq8mRa5fmq10eYTqLkq5mCQKtcJ6F56FV iXihMRCSqnuLIyRc2JaRd0zZbyor2dxO6OV7+opeRQ== X-Google-Smtp-Source: AGs4zMbVu6Xr8XeppIcdmbk8zRWTBVv6Vc64pLhR8t8W0u8aP7Hh9dGAeKSwNyyHzqc3meofOhhRkGTqdee/Kc/FOLg= X-Received: by 10.80.212.158 with SMTP id s30mr20024237edi.286.1512163080290; Fri, 01 Dec 2017 13:18:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.195.196 with HTTP; Fri, 1 Dec 2017 13:17:59 -0800 (PST) In-Reply-To: <87po7ygxai.fsf@nemesis.taht.net> 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> From: Bob McMahon Date: Fri, 1 Dec 2017 13:17:59 -0800 Message-ID: To: Dave Taht Cc: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= , make-wifi-fast@lists.bufferbloat.net, bloat Content-Type: multipart/alternative; boundary="94eb2c1affd03e6caa055f4de79f" 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: Fri, 01 Dec 2017 21:18:01 -0000 --94eb2c1affd03e6caa055f4de79f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 802.11 acks are packet or ampdu driven while tcp, being a byte protocol, acks bytes. Aligning these may not be straightforward. We test with different read() rates on the wifi clients as TCP is supposed to flow control the source's writes() as well. Wifi clients are starting to align their sleep cycles with "natural" periodicity in traffic so having larger aggregates can help both peak average throughput as well as power consumption. It's not obvious with Wifi that a faster RTT is always better. (Reminds me of the early days of NASA where many designed to reduce weight without keeping in account structural integrity, shave a few grams and lose a rocket.) Bob On Fri, Dec 1, 2017 at 9:42 AM, Dave Taht wrote: > Toke H=C3=B8iland-J=C3=B8rgensen writes: > > > Luca Muscariello writes: > > > >> If I understand the text right, FastACK runs in the AP and generates a= n > ACK > >> on behalf (or despite) of the TCP client end. > >> Then, it decimates dupACKs. > >> > >> This means that there is a stateful connection tracker in the AP. Not = so > >> simple. > >> It's almost, not entirely though, a TCP proxy doing Split TCP. > > > > Yeah, it's very much stateful, and tied closely to both TCP and the MAC > > layer. So it has all the usual middlebox issues as far as that is > > concerned... Also, APs need to transfer state between each other when > > the client roams. > > > > 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? > > I'd like to compare (eventually) what we are trying with cake's new ack > filter here, which at least doesn't lie to the endpoint. > > my guess, however, would be that the media access negotiation will > dominate the cost, and savings from (say) reducing 10 acks to 1 would > only be somewhere in the 5-20% range, for simple benchmarks. > > I think we might get a better rrul result, however, as we'd be able to > pack more big flows into a given aggregate, with less acks there. > > > > > -Toke > > _______________________________________________ > > Bloat mailing list > > Bloat@lists.bufferbloat.net > > https://lists.bufferbloat.net/listinfo/bloat > _______________________________________________ > Make-wifi-fast mailing list > Make-wifi-fast@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/make-wifi-fast > --94eb2c1affd03e6caa055f4de79f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
802.11 acks are packet or ampdu driven while tcp, being a = byte protocol, acks bytes.=C2=A0 Aligning these may not be straightforward.= =C2=A0 We test with different read() rates on the wifi clients as TCP is su= pposed to flow control the source's writes() as well.=C2=A0 Wifi client= s are starting to align their sleep cycles with "natural" periodi= city in traffic so having larger aggregates can help both peak average thro= ughput as well as power consumption.=C2=A0 It's not obvious with Wifi t= hat a faster RTT is always better.=C2=A0 (Reminds me of the early days of N= ASA where many designed to reduce weight without keeping in account structu= ral integrity, shave a few grams and lose a rocket.)

Bob

On Fri, Dec 1, 2017 at = 9:42 AM, Dave Taht <dave@taht.net> wrote:
Toke H=C3=B8iland-J=C3=B8rgensen <toke@toke.dk> writes:

> Luca Muscariello <luc= a.muscariello@gmail.com> writes:
>
>> If I understand the text right, FastACK runs in the AP and generat= es an ACK
>> on behalf (or despite) of the TCP client end.
>> Then, it decimates dupACKs.
>>
>> This means that there is a stateful connection tracker in the AP. = Not so
>> simple.
>> It's almost, not entirely though, a TCP proxy doing Split TCP.=
>
> Yeah, it's very much stateful, and tied closely to both TCP and th= e MAC
> layer. So it has all the usual middlebox issues as far as that is
> concerned... Also, APs need to transfer state between each other when<= br> > the client roams.
>
> It does increase single-flow TCP throughput by up to a factor of two,<= br> > though... Which everyone knows is the most important benchmark number = ;)

Were you always as cynical as I am?

I'd like to compare (eventually) what we are trying with cake's new= ack
filter here, which at least doesn't lie to the endpoint.

my guess, however, would be that the media access negotiation will
dominate the cost, and savings from (say) reducing 10 acks to 1 would
only be somewhere in the 5-20% range, for simple benchmarks.

I think we might get a better rrul result, however, as we'd be able to<= br> pack more big flows into a given aggregate, with less acks there.

>
> -Toke
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat= .net
> https://lists.bufferbloat.net/listinfo/bloat
____________________________= ___________________
Make-wifi-fast mailing list
Make-wifi-fast@list= s.bufferbloat.net
https://lists.bufferbloat.net/listinfo/mak= e-wifi-fast

--94eb2c1affd03e6caa055f4de79f--