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 CC0C33B29E; Thu, 21 Oct 2021 02:01:14 -0400 (EDT) Received: from mail-mx12.uio.no ([129.240.10.84]) 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 1mdR8W-006WGE-Le; Thu, 21 Oct 2021 08:01:08 +0200 Received: from ti0182q160-6611.bb.online.no ([95.34.115.34] helo=[192.168.1.7]) by mail-mx12.uio.no with esmtpsa (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.94.2) (envelope-from ) id 1mdR8V-00057q-K7; Thu, 21 Oct 2021 08:01:08 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Michael Welzl In-Reply-To: Date: Thu, 21 Oct 2021 08:01:05 +0200 Cc: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= , Rpm , Keith Winstein , Make-Wifi-fast Content-Transfer-Encoding: quoted-printable Message-Id: <92299A8B-7E2D-466A-9C55-AF6855BFF46E@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> <87a6j3e4jj.fsf@toke.dk> To: =?utf-8?Q?Anna_Brunstr=C3=B6m?= X-Mailer: Apple Mail (2.3608.120.23.2.7) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx12.uio.no: 95.34.115.34 is neither permitted nor denied by domain of ifi.uio.no) client-ip=95.34.115.34; envelope-from=michawe@ifi.uio.no; helo=[192.168.1.7]; X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5) X-UiO-Scanned: 40FB39BF92B3CF3B811904B77E398A0C9FC826A2 Subject: Re: [Rpm] [Make-wifi-fast] tack - reducing acks on wlans X-BeenThere: rpm@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: revolutions per minute - a new metric for measuring responsiveness List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2021 06:01:15 -0000 > On Oct 21, 2021, at 1:06 AM, Anna Brunstr=C3=B6m = wrote: >=20 > -----Original Message----- > From: Make-wifi-fast On = Behalf Of Toke H=C3=B8iland-J=C3=B8rgensen via Make-wifi-fast > Sent: den 21 oktober 2021 00:05 > To: Michael Welzl > Cc: Rpm ; Make-Wifi-fast = ; Keith Winstein = > Subject: Re: [Make-wifi-fast] tack - reducing acks on wlans >=20 > Michael Welzl writes: >=20 >>> 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... >>=20 >> 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 :) >=20 > Modifying the link layer for each wireless technology to convey the = information that the AP should send the TCP ACK, as done in the paper, = is quite complex from a deployment perspective I think. I agree, but this signal could be carried at a higher layer. > And it is also not all ACKs that can be replaced so not sure what the = reduction is in practice. Reducing the number of ACKs e2e seems = preferable I think. Did I miss something? I think they can remove all ACKs in the normal = case, maybe with quite special exceptions - e.g. when the rwnd changes, = perhaps... Cheers, Michael