From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.toke.dk (mail.toke.dk [IPv6:2a0c:4d80:42:2001::664]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id C0E0E3B29E; Wed, 20 Oct 2021 18:04:54 -0400 (EDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1634767490; bh=FVuaB/4TbvWZ6tOjUExpk+QsfB2vzERGtejUsu59O/Q=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=Dt6vN8Fv9dpLJKiPkV6aEgl/6oZgQGfwo5H1xOnXwkPc3GER0S0f2KEmYT9FgHlfY G53yI4oGwn4KCeemyIVmnGf/Df245pGas7wZ3mZMjTQTvMyHJWA+AYKyno28wdBrkj 2kaWI0A6F1RnQ/MHmFVyZpAg9Wymb4O4mhSR22KTuXbVJkVT7CnKmPlbAuLZqgIxoS aSmiYjaO8UrHAlDJQoIeBq5qF30PPIkQj0Fd0s6wDEsP6+VKaF8RJzSJjfovuIkAhH ot+av/OmpaTYUj/KpDHMpzTQcX+tmE3EkiXFCqoYVyF8x+2vvISjpXbp7u2UY95vgq jIeu4bAKl4NOQ== To: Michael Welzl Cc: Dave Taht , Rpm , Make-Wifi-fast , Keith Winstein In-Reply-To: <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> <03C5241C-D3C7-42E7-8552-4F6EAC626F66@ifi.uio.no> Date: Thu, 21 Oct 2021 00:04:48 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87a6j3e4jj.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 22:04:54 -0000 Michael Welzl writes: >> 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 spee= ds? >>>>>>>>=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 o= n the table would have it do this in case of tunneling TCP/IP over QUIC, bu= t not in case of QUIC itself - but to me, this isn't necessarily good desig= n? 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 sta= te >>>> 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 :) Well, I consider anything that has to run on an access point complex just from a "get someone to ship this without messing it up" point of view ;) > But yes, whether it's worth it is questionable, of course; if TACK is > good enough, it'll be easier to deploy of course. I was referring to the graph in the paper that shows they get pretty close to single-direction UDP with TACK... -Toke