[Make-wifi-fast] [Bloat] benefits of ack filtering
luca.muscariello at gmail.com
Fri Dec 1 08:22:49 EST 2017
I think only IPSEC would be a problem for fastACK but not TLS.
On Fri, Dec 1, 2017 at 2:13 PM, Кирилл Луконин <klukonin at gmail.com> 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 currently
> see an extensive use of encryption techniques like IPSec."
> But what about TLS ?
> As for me, this technology will never work in most cases.
> Best regards,
> Lukonin Kirill.
> 2017-12-01 17:53 GMT+05:00 Toke Høiland-Jørgensen <toke at toke.dk>:
> > Jan Ceuleers <jan.ceuleers at gmail.com> 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 related discussion going on over on the make-wifi-fast list
> > related to the FastACK scheme proposed by Meraki at this year's IMC:
> > https://conferences.sigcomm.org/imc/2017/papers/imc17-final203.pdf
> > It basically turns link-layer ACKs into upstream TCP ACKs (and handles
> > some of the corner cases resulting from this) and also seems to contain
> > an ACK compression component.
> > -Toke
> > _______________________________________________
> > Make-wifi-fast mailing list
> > Make-wifi-fast at lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/make-wifi-fast
> Best Regards,
> Lukonin Kirill
> Make-wifi-fast mailing list
> Make-wifi-fast at lists.bufferbloat.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Make-wifi-fast