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 Fri, Dec 1, 2017 at 1:53 PM, Toke Høiland-Jørgensen <t...@toke.dk> wrote: > 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 > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat >
_______________________________________________ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
