Re: [Rpm] [Make-wifi-fast] tack - reducing acks on wlans

[Michael Welzl <michawe@ifi.uio.no>]

Hi,

This is interesting indeed - though technically, I'd say it's the next best thing, a compromise that's needed because apparently this old ARQ proxy idea isn't deployable (or wasn't seen?):
https://orbilu.uni.lu/bitstream/10993/6555/1/arqproxy.pdf
This ARQ proxy removes all TCP ACKs over the wireless segment. It doesn't need to put the ACKs inside LL-ACKs like HACK (described in the TACK paper), and hence it doesn't need a change to NICs like HACK.  It just keeps track of incoming data packets and LL-ACKs, and takes care of L4 ACKing.

Now, the ARQ proxy needs a change to the AP, whereas the TACK idea (from a quick look) doesn't. That's a clear benefit of the TACK approach - changing less elements in the system. Also, the ARQ proxy as described in the paper above is probably transparent, which can cause ossification - but it won't need to be transparent.

I wonder: could someone standardize a negotiation between the (trusted, because the OS knows that this is indeed the AP) AP and the wireless end hosts, so that the AP can say: "I can ACK for you, please don't ACK"?
With this, in principle, it should be possible to completely remove L4 ACKs on the wireless segment, and this would be better for all.

Am I being naive? Why can't such an ARQ proxy be deployed? Is it just because standardizing this negotiation is too difficult, or would it also be too computationally heavy for an AP perhaps, at high speeds?

Cheers,
Michael


> On 19 Oct 2021, at 22:12, Dave Taht <dave.taht@gmail.com> wrote:
> 
> Somehow I'd missed this paper... thx for the steer, keith.
> 
> https://cs.stanford.edu/~keithw/tack-sigcomm2020.pdf
> 
> -- 
> Fixing Starlink's Latencies: https://www.youtube.com/watch?v=c9gLo6Xrwgw
> 
> Dave Täht CEO, TekLibre, LLC
> _______________________________________________
> Make-wifi-fast mailing list
> Make-wifi-fast@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/make-wifi-fast