From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id ADD973CB43; Wed, 20 Oct 2021 03:00:58 -0400 (EDT) Received: from mail-mx10.uio.no ([129.240.10.27]) by mail-out02.uio.no with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1md5ap-00F2M8-Du; Wed, 20 Oct 2021 09:00:55 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx10.uio.no with esmtpsa (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.94.2) (envelope-from ) id 1md5ak-000AaK-MP; Wed, 20 Oct 2021 09:00:55 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Michael Welzl In-Reply-To: Date: Wed, 20 Oct 2021 09:00:48 +0200 Cc: Make-Wifi-fast , Rpm , Keith Winstein Content-Transfer-Encoding: quoted-printable Message-Id: <4BD0AC02-62FB-4AE4-B83B-BAF5CCEA2B24@ifi.uio.no> References: To: Dave Taht X-Mailer: Apple Mail (2.3445.9.1) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx10.uio.no: 129.240.68.135 is neither permitted nor denied by domain of ifi.uio.no) client-ip=129.240.68.135; envelope-from=michawe@ifi.uio.no; helo=boomerang.ifi.uio.no; X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5) X-UiO-Scanned: B58E5DDB27BA33C10DEFD02EE450ED7276D6DC43 Subject: Re: [Make-wifi-fast] tack - reducing acks on wlans X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2021 07:00:58 -0000 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 wrote: >=20 > Somehow I'd missed this paper... thx for the steer, keith. >=20 > https://cs.stanford.edu/~keithw/tack-sigcomm2020.pdf >=20 > --=20 > Fixing Starlink's Latencies: = https://www.youtube.com/watch?v=3Dc9gLo6Xrwgw >=20 > Dave T=C3=A4ht CEO, TekLibre, LLC > _______________________________________________ > Make-wifi-fast mailing list > Make-wifi-fast@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/make-wifi-fast