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 87DA33B29E; Wed, 20 Oct 2021 07:52:39 -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=1634730756; bh=qt2d84/24RL3gXofY37oYjXXs8dOkhD8vwSuvznkUT4=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=nrZNu4lNC6Y+2E/DV0/0pC8sPaSu+++g53b2GLm3yeS/v4DQ4kP/s5+hPqTOl9MUk ABmpX3xNDRTQAk8xdcMUN/4BwUQecIckjZ3Z+GePewrWknpli8pf6jzYN51wApns76 Msy0He/cRBvDYzUxEYoWMHb5PSlaA0q6izwsKfrkrDvROwOexgamu/3wa0RQzg0X0m iSbVWCmm/WF5IBWS9kYRHiFgk3sr3IctrAXYhC7TfellNWrio8kaFQ976LLc43HyBO R27T7UW4mss/5+S+gHBxXTa8xz7HrCXWFp83BnKNbJlk5tuOQu4vzmxPHErAv/nfa2 ysZRJsXTU0pVw== To: Michael Welzl Cc: Dave Taht , Rpm , Make-Wifi-fast , Keith Winstein In-Reply-To: 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> Date: Wed, 20 Oct 2021 13:52:36 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87bl3jgbgb.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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: Wed, 20 Oct 2021 11:52:39 -0000 Michael Welzl writes: >> 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? > > Wellllll.... I'm not 100% sure. If I understood it correctly, ideas on th= e table would have it do this in case of tunneling TCP/IP over QUIC, but no= t in case of QUIC itself - but to me, this isn't necessarily good design? = Because: =3D> > > >> In any case, it would require clients to negotiate >> a proxy session with the AP and trust it to do that properly? > > =3D> Yes. > > >> 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? > > 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. 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? -Toke