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

[Michael Welzl]

> On 20 Oct 2021, at 13:52, Toke Høiland-Jørgensen <toke at toke.dk> wrote:
> 
> Michael Welzl <michawe at ifi.uio.no> writes:
> 
>>> 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.
> 
> 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?

Depends - this is what explicitly signaling this capability could solve.

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.

Cheers,
Michael