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

["Toke Høiland-Jørgensen" <toke@toke.dk>]

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  :)

Well, I consider anything that has to run on an access point complex
just from a "get someone to ship this without messing it up" point of
view ;)

> But yes, whether it's worth it is questionable, of course; if TACK is
> good enough, it'll be easier to deploy of course.

I was referring to the graph in the paper that shows they get pretty
close to single-direction UDP with TACK...

-Toke