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

2017-12-01 Thread Bob McMahon
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

Re: [Bloat] benefits of ack filtering

2017-12-01 Thread Juliusz Chroboczek
>> 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 ;-) ___ Bloat ma

Re: [Bloat] benefits of ack filtering

2017-12-01 Thread Dave Taht
On Fri, Dec 1, 2017 at 10:57 AM, Luca Muscariello wrote: > https://www.cisco.com/c/en/us/products/collateral/wireless/aironet-3700-series/white-paper-c11-735947.html > Good news all over. I wonder what happens on cisco against the suite of tests toke made available here: https://www.cs.kau.se/to

Re: [Bloat] benefits of ack filtering

2017-12-01 Thread Luca Muscariello
https://www.cisco.com/c/en/us/products/collateral/wireless/aironet-3700-series/white-paper-c11-735947.html On Fri 1 Dec 2017 at 19:43, Dave Taht wrote: > Luca Muscariello writes: > > > For highly asymmetric links, but also shared media like wifi, QUIC might > be a > > better playground for opt

Re: [Bloat] benefits of ack filtering

2017-12-01 Thread Dave Taht
Luca Muscariello writes: > For highly asymmetric links, but also shared media like wifi, QUIC might be a > better playground for optimisations. > Not pervasive as TCP though and maybe off topic in this thread. I happen to really like QUIC, but a netperf-style tool did not exist for it when I las

Re: [Bloat] benefits of ack filtering

2017-12-01 Thread Dave Taht
Toke Høiland-Jørgensen writes: > Luca Muscariello writes: > >> If I understand the text right, FastACK runs in the AP and generates 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 s

Re: [Bloat] Bufferbloat in high resolution + non-stationarity

2017-12-01 Thread Jonathan Morton
If so, that's a step in the right direction. I know of a few "old guard" protocols which typically use appropriate DSCPs too. But YouTube doesn't, and neither do any of the major BitTorrent implementations (despite us asking nicely), nor typical VoIP clients, nor multiplayer games. Those are the

Re: [Bloat] benefits of ack filtering

2017-12-01 Thread Toke Høiland-Jørgensen
Luca Muscariello writes: > If I understand the text right, FastACK runs in the AP and generates 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 t

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

2017-12-01 Thread Luca Muscariello
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 networks, we do not currentl

Re: [Bloat] benefits of ack filtering

2017-12-01 Thread Luca Muscariello
If I understand the text right, FastACK runs in the AP and generates 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. On

Re: [Bloat] benefits of ack filtering

2017-12-01 Thread Toke Høiland-Jørgensen
Jan Ceuleers writes: > On 01/12/17 01:28, David Lang wrote: >> Stop thinking in terms of single-flow benchmarks and near idle >> 'upstream' paths. > > Nobody has said it so I will: on wifi-connected endpoints the upstream > acks also compete for airtime with the downstream flow. There's a relate

Re: [Bloat] benefits of ack filtering

2017-12-01 Thread Luca Muscariello
For highly asymmetric links, but also shared media like wifi, QUIC might be a better playground for optimisations. Not pervasive as TCP though and maybe off topic in this thread. If the downlink is what one want to optimise, using FEC in the downstream, in conjunction with flow control could be ve

Re: [Bloat] Bufferbloat in high resolution + non-stationarity

2017-12-01 Thread Michael Welzl
I thought that some browsers already use various DSCPs when running WebRTC? > On Nov 30, 2017, at 9:09 PM, Jonathan Morton wrote: > > Cake already supports treating CS1 as less-than-besteffort by default. > Adding more codepoints to that list is easy. > > The trick is getting applications to

Re: [Bloat] benefits of ack filtering

2017-12-01 Thread Sebastian Moeller
Hi All, you do realize that the worst case is going to stay at 35KPPS? If we assume simply that the 100Mbps download rate is not created by a single flow but by many flows (say 70K flows) the discussed ACK frequency reduction schemes will not work that well. So ACK thinning is a nice optimizati