[Rpm] tack - reducing acks on wlans

[Sebastian Moeller]

Just reading the introduction:
"It is well-studied that medium acquisition overhead in WLAN based on the IEEE 802.11 medium access control (MAC) protocol [11] can severely hamper TCP throughput, and TCP’s many small ACKs are one reason [53, 69]. Basically, TCP sends an ACK for every one or two packets (i.e., received-packet-driven) [7, 15]. ACKs share the same medium route with data packets, causing similar medium access overhead despite the much smaller size of the ACK- s [8, 31, 36, 50, 58]. Contentions and collisions, as well as the wasted wireless resources by ACKs, lead to significant throughput decline on the data path (see §3.2)."

makes me wonder whether the proper solution would not be to exchange the WiFi MAC with something that is actually suited for existing traffic patterns.... 

On the other hand the Reno-ACK scheme is probably not really optimal today (if it ever was in the past) so improving transport-level feed-back schemes seems a worthy goal in itself.

But really, a packet network should be able to simply transport all packets reasonably efficiently..., no?

Regards
	Sebastian


> On Oct 19, 2021, at 22:12, Dave Taht via Rpm <rpm at lists.bufferbloat.net> 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
> _______________________________________________
> Rpm mailing list
> Rpm at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/rpm