From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 ADE6E3BA8E for ; Thu, 30 Nov 2017 04:03:55 -0500 (EST) Received: from [192.168.250.101] ([134.76.241.253]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LzGV3-1fF6EG2EBV-014ScC; Thu, 30 Nov 2017 10:03:49 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Sebastian Moeller In-Reply-To: Date: Thu, 30 Nov 2017 10:03:49 +0100 Cc: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= , make-wifi-fast@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: References: <87lgionrl5.fsf@toke.dk> To: =?utf-8?Q?Dave_T=C3=A4ht?= X-Mailer: Apple Mail (2.3273) X-Provags-ID: V03:K0:ba5anS9hrJFxt73oOkQWsMzVAQtJHRqc92ml8ur5NKTYCxhmyzN dBUcFl1pec4S6rteygfSSfLQ6FSJgyGq+S8DK61i4OkiMYVOGQViSGUP+BjCZ3Zjq2vTUGW bVPQugbNYM6NAXxlcWza2nWyWE2z8sIYY1rheJU0tHRFr8j50qI2CHVFkB6xuWPcFxH88Vs vl4U1J0JC/mDLfXs/wqBg== X-UI-Out-Filterresults: notjunk:1;V01:K0:xTGfjA5mq20=:1TAKP1lsTciHhVsizM1PCc 3VZ9bg2pEQfxrKDo+2nCqPRhPHOuyn7ZIRCx2FLh1a3GbboDs3CIA7sMcDxFKranvzNvKw6O3 YVZR1K85kKsSGlrsJq4scZ2Tw3Msx7nYQDvySxi/i1SuUKVlqq6Fo3dVWBlEgMPS4lCNNsH6p gfUMcyf6HsqjrbZgx+Wi5Jq0s+dr08QzGtqBN6H8rl5OrG7MqKldXxl56PvZBs7736OU7FG07 y7/oPYRmjTWNcYi0qe48M2eKZMG3S+NApAg+Y750wA5gs3AcFNPaRBrtqaAMLTat6xIRvXlOI 8rv+tk90toMfeW3ts2hMRepMyUewkmawzLn6xwNhEdylFfgskX/SYGOAc0gyO25u2V2C0hJlB 0tVRDKxjiDkwwTdAZGeLl3i5ElwCe4jGmj0/HJIsEXmBuTEANC1gy/E29+z8IFS/9a1LeEmGd UuXm0idm8WG+nrjoGPMTh96H7L1gTeeJriC0t0Td3xITM7NgzH4ftA3jZuYQnDD0oeFIhCtZk Kq282MIM7zjD9PHbIeBmlqocTRGSkn3755zF6iBuDLXfb9/zqrtyrlRzSnTB4u9XtvKKW60HR 5z1ATq+d7KuN2f52i0nOsfTatgF3UBXEhAXFvE8/8k5HxX6Nugl5C1F8yMMaffdmDV/+PVfa/ AfGd735SLP4d8rh7x7teViLlCqfroQP9ZZH+HxP5Ve7SlpCgrm9a2VAEJIyM9fBtO2obaBlIe Y/xW7AZaA7btBkji8fjGqj+TYmmyeU2bgeO1eUkrBm20gwmX9Ia9eYe2wxm26EB4N4r14jQUa JmqhThLFJFkevNig+jeMQgq0o2XLkSP36LWHrCQbf6uRLDOKio= Subject: Re: [Make-wifi-fast] Fwd: Re: [iccrg] TCP behavior across WiFi pointers ? 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: Thu, 30 Nov 2017 09:03:56 -0000 > On Nov 30, 2017, at 09:07, Dave Taht wrote: >=20 > "We propose that receiving of an 802.11 ACK is a reliable hint that > the corresponding TCP segments will eventually be processed by the > receiver=E2=80=99s transport layer. On receipt of an 802.11 ACK from = the > wireless client, the AP will proactively generate a fake TCP ACK on > behalf of the TCP receiver, forwarding it to the TCP sender. This > results in the TCP ACKs arriving sooner at the sender, eliminating the > delay variation induced by medium contention at the receiver. Since > the receiver will still send a TCP ACK, these now-duplicate TCP ACKs > should be suppressed by the AP. The TCP sender is thus shielded in the > revers..." Now, I admit I am no expert here, but that is crazy talk, making ack = thinning look sane (note, I believe that thinning is _sane_ if = explicitly opted-in by the end-user, less so if transparently and = proactively performed by some hop along the path not under control of = the end-users; I have no real opinion on its sanity as a measure against = actual congestion.). But this is an active (crazy?) bet on the rest of = the rest of the link being error free. In other words it is a gamble = which will probably improve the average while also causing more/more = extreme extremes, I wonder what measures they use to support their .=20 Mildly funny side-note fast in german literally means "almost" in that = sense the moniker "fastACK" looks actually quite fitting. QUESTION: "The receipt of an 802.11 ACK at the AP triggers it to send the = corresponding fast ACK to the TCP sender, thereby moving it past the = current sequence number. The client on the other hand would send a = duplicate ACK for this lost segment. This is a problem since the TCP = sender might not hold that packet anymore in its outgoing bu er, thereby = disrupting the TCP session. To avoid this, the FastACK agent inserts = each data packet into its local cache before forwarding it downstream. A = duplicate ACK from the client then triggers local retransmissions from = this cache, on behalf of the TCP sender. Second, local retransmissions = are cheaper (and low-overhead) as compared to the end-to-end = retransmissions. Further, it also avoids lowering the congestion window = of the TCP sender, and maintaining the high end-to-end data ow." Does that mean that the AP now needs to allow up to a full window of = buffering for each TCP flow it fakeACKs? I have a hunch that the _real_ solution would lie in making the 802.11 = MAC have less per packet overhead, so that the need for excessive = aggregation would go away, because in the end fastACK aims at lying to = the endpoints that there is a relative stable link with nicely bound = latency and latency variance when in reality the actual link does not = show that, but what do I know... Then again, since the wifi MAC seems unlikely to change this might be as = good as it gets... >=20 >=20 > On Thu, Nov 30, 2017 at 12:04 AM, Dave Taht = wrote: >> wow. *median* of 7 interfering APs at 2.4ghz. 10% with more than 29 = interferers. >>=20 >> On Wed, Nov 29, 2017 at 11:39 PM, Toke H=C3=B8iland-J=C3=B8rgensen = wrote: >>> The folks over at Meraki had a paper at this year's IMC talking = about >>> TCP over WiFi. >>>=20 >>> -Toke >>>=20 >>>=20 >>>=20 >>> ---------- Forwarded message ---------- >>> From: Simon Barber >>> To: Aaron Falk >>> Cc: Toerless Eckert , iccrg@irtf.org, = tsv-area@ietf.org, Michael Welzl , Mark Allman = >>> Bcc: >>> Date: Wed, 29 Nov 2017 16:41:04 -0800 >>> Subject: Re: [iccrg] TCP behavior across WiFi pointers ? >>> We=E2=80=99ve been doing some studies and work in this area at = Meraki. >>>=20 >>> https://conferences.sigcomm.org/imc/2017/papers/imc17-final203.pdf >>>=20 >>> Simon >>>=20 >>>=20 >>> On Nov 29, 2017, at 7:17 AM, Aaron Falk = wrote: >>>=20 >>> Hey Mark- >>>=20 >>> Didn't you do some work on TCP over wifi a while ago? >>>=20 >>> --aaron >>>=20 >>> On Wed, Nov 8, 2017 at 1:33 PM Michael Welzl = wrote: >>>>=20 >>>> I would think that 1) there are probably pointers, and 2) the = people who have them should be on the ICCRG list, which I=E2=80=99m = cc=E2=80=99ing. >>>>=20 >>>> I suggest for this to be the last email that includes tsvarea so = that the thread entirely moves to ICCRG. >>>>=20 >>>>=20 >>>>> On Nov 8, 2017, at 6:42 PM, Toerless Eckert = wrote: >>>>>=20 >>>>> Any pointers to work analyzing the differences in behavior when = TCP is run >>>>> across WiFi as opposed to wired ? Especially with WiFi in the home = ? >>>>>=20 >>>>> I am primarily thinking that there could be a higher demand for >>>>> TCP (end-to-end) retransmissions when using WiFi because the = L2/WiFi >>>>> local retransmissions are insufficient. And if so, what the = characteristics >>>>> of those end-to-end retransmissions is (would assume they would be = larger >>>>> than N msec, where N is whatever the L2/wifi protection window is, = which >>>>> unfortunately i don't know). >>>>>=20 >>>>> Asking because we've got the poor "must-sit-in-back-of-the-bus" = traffic >>>>> called IP multicast that is not protected by L2/wifi = retransmissions at >>>>> all and now we're wondering if carrying it over TCP as a = workaround >>>>> could help, and therefore trying to educate myself on specific = known >>>>> issue left when running traffic over TCP over WiFi. >>>>>=20 >>>>> If any other TSV or other WG mailing list might be a better place = to >>>>> ask. pls. let me know. >>>>>=20 >>>>> Thank! >>>>> Toerless >>>>>=20 >>>>=20 >>> _______________________________________________ >>> iccrg mailing list >>> iccrg@irtf.org >>> https://www.irtf.org/mailman/listinfo/iccrg >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> iccrg mailing list >>> iccrg@irtf.org >>> https://www.irtf.org/mailman/listinfo/iccrg >>>=20 >>> _______________________________________________ >>> Make-wifi-fast mailing list >>> Make-wifi-fast@lists.bufferbloat.net >>> https://lists.bufferbloat.net/listinfo/make-wifi-fast >>=20 >>=20 >>=20 >> -- >>=20 >> Dave T=C3=A4ht >> CEO, TekLibre, LLC >> http://www.teklibre.com >> Tel: 1-669-226-2619 >=20 >=20 >=20 > --=20 >=20 > Dave T=C3=A4ht > CEO, TekLibre, LLC > http://www.teklibre.com > Tel: 1-669-226-2619 > _______________________________________________ > Make-wifi-fast mailing list > Make-wifi-fast@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/make-wifi-fast