[Make-wifi-fast] tack - reducing acks on wlans

[Michael Welzl]

> On 20 Oct 2021, at 12:44, Toke Høiland-Jørgensen <toke at toke.dk> wrote:
> 
> Michael Welzl <michawe at ifi.uio.no> writes:
> 
>>> On 20 Oct 2021, at 11:44, Toke Høiland-Jørgensen <toke at toke.dk> wrote:
>>> 
>>> Michael Welzl <michawe at ifi.uio.no> writes:
>>> 
>>>> 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?
>>> 
>>> Immediate thought: this won't work for QUIC
>> 
>> .... as-is, true, though MASQUE is still being defined. Is this an
>> argument for defining it accordingly?
> 
> 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 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:  =>


> In any case, it would require clients to negotiate
> a proxy session with the AP and trust it to do that properly?

=> 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.

Someone showed me a paper which lets such proxies ACK by reflecting parts of the encrypted packet... I don't remember the title now and don't have a pointer, but: it can be done anyway (if the sender is able to parse these ACKs). Not being a part of the standard means nobody will implement such a sender though.

Cheers,
Michael