From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-out01.uio.no (mail-out01.uio.no [IPv6:2001:700:100:10::50]) (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 DEA113B29E; Wed, 20 Oct 2021 13:08:19 -0400 (EDT) Received: from mail-mx10.uio.no ([129.240.10.27]) by mail-out01.uio.no with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1mdF4Z-005KZB-Co; Wed, 20 Oct 2021 19:08:15 +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 1mdF4Y-000Dp3-CK; Wed, 20 Oct 2021 19:08:15 +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: <8735ovg045.fsf@toke.dk> Date: Wed, 20 Oct 2021 19:08:13 +0200 Cc: Dave Taht , Rpm , Make-Wifi-fast , Keith Winstein Content-Transfer-Encoding: quoted-printable Message-Id: <03C5241C-D3C7-42E7-8552-4F6EAC626F66@ifi.uio.no> References: <4BD0AC02-62FB-4AE4-B83B-BAF5CCEA2B24@ifi.uio.no> <87lf2of2sl.fsf@toke.dk> <09884015-6428-4402-BE61-9091006D1FB8@ifi.uio.no> <87ee8gf013.fsf@toke.dk> <87bl3jgbgb.fsf@toke.dk> <2BE60847-5C04-4EF5-B1B1-F0A21581AB63@ifi.uio.no> <8735ovg045.fsf@toke.dk> To: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= 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: 1C6F89228E52246E11A6DFC78ABA21C953F8D854 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 17:08:20 -0000 > On 20 Oct 2021, at 17:57, Toke H=C3=B8iland-J=C3=B8rgensen = wrote: >=20 > Michael Welzl writes: >=20 >>> On 20 Oct 2021, at 13:52, Toke H=C3=B8iland-J=C3=B8rgensen = wrote: >>>=20 >>> Michael Welzl writes: >>>=20 >>>>> On 20 Oct 2021, at 12:44, Toke H=C3=B8iland-J=C3=B8rgensen = wrote: >>>>>=20 >>>>> Michael Welzl writes: >>>>>=20 >>>>>>> On 20 Oct 2021, at 11:44, Toke H=C3=B8iland-J=C3=B8rgensen = wrote: >>>>>>>=20 >>>>>>> Michael Welzl writes: >>>>>>>=20 >>>>>>>> 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? >>>>>>>=20 >>>>>>> Immediate thought: this won't work for QUIC >>>>>>=20 >>>>>> .... as-is, true, though MASQUE is still being defined. Is this = an >>>>>> argument for defining it accordingly? >>>>>=20 >>>>> MASQUE is proxying, right? Not quite sure if it's supposed to be = also >>>>> MITM'ing the traffic? >>>>=20 >>>> Wellllll.... I'm not 100% sure. If I understood it correctly, ideas = on the table would have it do this in case of tunneling TCP/IP over = QUIC, but not in case of QUIC itself - but to me, this isn't necessarily = good design? Because: =3D> >>>>=20 >>>>=20 >>>>> In any case, it would require clients to negotiate >>>>> a proxy session with the AP and trust it to do that properly? >>>>=20 >>>> =3D> Yes. >>>>=20 >>>>=20 >>>>> This may >>>>> work for a managed setup in an enterprise, but do you really = expect me >>>>> to be OK with any random access point in a coffee shop being a = MITM? >>>>=20 >>>> MiTM is a harsh term for just being able to ACK on my behalf. Some >>>> capabilities could be defined, as long as they're indeed defined >>>> clearly. So I don't see why "yes, you can ACK my packets on my = behalf >>>> when you get a LL-ACK from me" is MiTM'ing. I believe that things = are >>>> now all being lumped together, which may be why the design may end = up >>>> being too prohibitive. >>>=20 >>> Right, okay, but even setting aside the encryption issue, you're = still >>> delegating something that has potentially quite a significant impact = on >>> your application's performance to an AP that (judging by the sorry = state >>> of things today) is 5-10 years out of date compared to the software >>> running on your own machine. Not sure that's such an attractive >>> proposition? >>=20 >> Depends - this is what explicitly signaling this capability could = solve. >>=20 >> Take TCP, for example: if I'm all hyped on L4S, I may not want to >> delegate ACKing to an AP that doesn't support ACKing without support >> for accurate ECN signaling. If I do MPTCP and see support from the >> peer, then perhaps I don't want this capability at all. If I don't >> care about these two things... well, then, ACKing hasn't changed very >> much for several years. I may want to include some initial option >> information in that signal, for the AP to relay - e.g. about window >> scaling and such. I suspect that QUIC / MASQUE ACKing is also going = to >> stabilize somewhat at some point in time. >=20 > Still a lot of complexity for something that (according to that TACK > paper) is only a marginal improvement over what can be achieved > end-to-end... It's not exactly huge complexity compared to many of the other things we = have, and I'm not sure the improvement is marginal: this may depend on = various things, such as the number of nodes... it's a 100% reduction of = ACK traffic :) But yes, whether it's worth it is questionable, of course; if TACK is = good enough, it'll be easier to deploy of course. Cheers, Michael