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

[Michael Welzl <michawe@ifi.uio.no>]

> On Oct 21, 2021, at 1:06 AM, Anna Brunström <anna.brunstrom@kau.se> wrote:
> 
> -----Original Message-----
> From: Make-wifi-fast <make-wifi-fast-bounces@lists.bufferbloat.net> On Behalf Of Toke Høiland-Jørgensen via Make-wifi-fast
> Sent: den 21 oktober 2021 00:05
> To: Michael Welzl <michawe@ifi.uio.no>
> Cc: Rpm <rpm@lists.bufferbloat.net>; Make-Wifi-fast <make-wifi-fast@lists.bufferbloat.net>; Keith Winstein <keithw@cs.stanford.edu>
> Subject: Re: [Make-wifi-fast] tack - reducing acks on wlans
> 
> Michael Welzl <michawe@ifi.uio.no> writes:
> 
>>> On 20 Oct 2021, at 17:57, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>>> 
>>> Michael Welzl <michawe@ifi.uio.no> writes:
>>> 
>>>>> On 20 Oct 2021, at 13:52, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>>>>> 
>>>>> Michael Welzl <michawe@ifi.uio.no> writes:
>>>>> 
>>>>>>> On 20 Oct 2021, at 12:44, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>>>>>>> 
>>>>>>> Michael Welzl <michawe@ifi.uio.no> writes:
>>>>>>> 
>>>>>>>>> On 20 Oct 2021, at 11:44, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>>>>>>>>> 
>>>>>>>>> Michael Welzl <michawe@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.
>>> 
>>> 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  :)
> 
> 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