Re: [Bloat] [Make-wifi-fast] benefits of ack filtering

TLS works over TCP, so the TCP headers are not encrypted. Simon Sent with AquaMail for Android http://www.aqua-mail.com On December 11, 2017 8:17:47 AM Кирилл Луконин wrote: As I noticed from the Meraki document: "FastACK also relies on packet inspection, and will not

Re: [Bloat] [Make-wifi-fast] benefits of ack filtering

As I noticed from the Meraki document: "FastACK also relies on packet inspection, and will not work when payload is encrypted. However, in our networks, we do not currently see an extensive use of encryption techniques like IPSec." But what about TLS ? As for me, this technology will never work

Re: [Bloat] [Make-wifi-fast] benefits of ack filtering

On 04/12/17 10:44 AM, Juliusz Chroboczek wrote: In a previous life I did some work on the optimization (by remote proxying) of the SMB protocol used by Samba [...] Eventually we said the heck with it, and sat Samba on top of a different protocol entirely, The audience are waiting with held

Re: [Bloat] [Make-wifi-fast] benefits of ack filtering

> In a previous life I did some work on the optimization (by remote > proxying) of the SMB protocol used by Samba [...] Eventually we said > the heck with it, and sat Samba on top of a different protocol entirely, The audience are waiting with held breath for more details. -- Juliusz

Re: [Bloat] [Make-wifi-fast] benefits of ack filtering

On 03/12/17 10:44 PM, Dave Taht wrote: More generally, the case where you have a queue containing acks, stored up for whatever reason (congestion, media access, asymmetry), is a chance for a middlebox or host to do something "smarter" to thin them out. Acks don't respond to conventional

Re: [Bloat] [Make-wifi-fast] benefits of ack filtering

On Sun, Dec 3, 2017 at 12:14 PM, Sebastian Moeller wrote: > > > On December 3, 2017 8:54:40 PM GMT+01:00, Juliusz Chroboczek > wrote: >>> Many would kill for a 10:1 DOCSIS connection. 50:1 is not rare, and I >>> have personally been subscribed to a near 100:1

Re: [Bloat] [Make-wifi-fast] benefits of ack filtering

On December 3, 2017 8:54:40 PM GMT+01:00, Juliusz Chroboczek wrote: >> Many would kill for a 10:1 DOCSIS connection. 50:1 is not rare, and I >> have personally been subscribed to a near 100:1 service. > >Some people should not be allowed to design networks. > >> The DOCSIS shaper

Re: [Bloat] [Make-wifi-fast] benefits of ack filtering

> Many would kill for a 10:1 DOCSIS connection. 50:1 is not rare, and I > have personally been subscribed to a near 100:1 service. Some people should not be allowed to design networks. > The DOCSIS shaper deals with ethernet frames so 58 / 1518 bytes. Could you please point me to details of the

Re: [Bloat] [Make-wifi-fast] benefits of ack filtering

> I can buy 300/10 megabit/s access from my cable provider. Don't! > If I understand correctly, DOCSIS has ~1ms sending opportunities > upstream. So sending more than 1kPPS of ACKs is meaningless, as these ACKs > will just come back to back at wire-speed as the CMTS receives them from > the

Re: [Bloat] [Make-wifi-fast] benefits of ack filtering

My understanding per the thread is a last hop wifi link. I could be wrong though. Bob On Sun, Dec 3, 2017 at 2:35 AM, Juliusz Chroboczek wrote: > > It might be preferred to modify EDCA parameters to reduce media access > > latencies for TCP acks rather than spoof them. > > I'm

Re: [Bloat] [Make-wifi-fast] benefits of ack filtering

On 03/12/2017 13:57, Juliusz Chroboczek wrote: > A TCP Ack is 40 bytes. A data packet is up to 1500 bytes. > > As far as I know, DOCSIS has an asymmetry factor that is between 4 and 10, > depending on the deployment. With worst case asymmetry being 10, this > means that you can send an Ack for

Re: [Bloat] [Make-wifi-fast] benefits of ack filtering

On 4 December 2017 at 00:27, Juliusz Chroboczek wrote: >>> I'm lost here. What exact problem is the ACK hack supposed to work >>> around? Ridiculous amount of asymmetry in the last-hop WiFi link, or >>> outrageous amounts of asymmetry in a transit link beyond the last hop? > >> My

Re: [Bloat] [Make-wifi-fast] benefits of ack filtering

On Sun, 3 Dec 2017, Juliusz Chroboczek wrote: As far as I know, DOCSIS has an asymmetry factor that is between 4 and 10, depending on the deployment. With worst case asymmetry being 10, this I can buy 300/10 megabit/s access from my cable provider. So that's a lot worse. My cable box has 16

Re: [Bloat] [Make-wifi-fast] benefits of ack filtering

>> I'm lost here. What exact problem is the ACK hack supposed to work >> around? Ridiculous amount of asymmetry in the last-hop WiFi link, or >> outrageous amounts of asymmetry in a transit link beyond the last hop? > My understanding is that the issue that gave rise to this discussion was >

Re: [Bloat] [Make-wifi-fast] benefits of ack filtering

On 03/12/17 11:35, Juliusz Chroboczek wrote: > I'm lost here. What exact problem is the ACK hack supposed to work > around? Ridiculous amount of asymmetry in the last-hop WiFi link, or > outrageous amounts of asymmetry in a transit link beyond the last hop? My understanding is that the issue

Re: [Bloat] [Make-wifi-fast] benefits of ack filtering

> It might be preferred to modify EDCA parameters to reduce media access > latencies for TCP acks rather than spoof them. I'm lost here. What exact problem is the ACK hack supposed to work around? Ridiculous amount of asymmetry in the last-hop WiFi link, or outrageous amounts of asymmetry in a

Re: [Bloat] [Make-wifi-fast] benefits of ack filtering

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

Re: [Bloat] [Make-wifi-fast] benefits of ack filtering

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

Re: [Bloat] [Make-wifi-fast] benefits of ack filtering

I think only IPSEC would be a problem for fastACK but not TLS. On Fri, Dec 1, 2017 at 2:13 PM, Кирилл Луконин wrote: > As I noticed from the Meraki document: > > "FastACK also relies on packet inspection, and will not work when > payload is encrypted. However, in our