I think only IPSEC would be a problem for fastACK but not TLS. On Fri, Dec 1, 2017 at 2:13 PM, Кирилл Луконин <kluko...@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 <t...@toke.dk>: > > Jan Ceuleers <jan.ceule...@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-f...@lists.bufferbloat.net > > https://lists.bufferbloat.net/listinfo/make-wifi-fast > > > > -- > Best Regards, > Lukonin Kirill > _______________________________________________ > Make-wifi-fast mailing list > make-wifi-f...@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/make-wifi-fast
_______________________________________________ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat