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

[Michael Welzl]

> On Oct 21, 2021, at 1:20 AM, Omer Shapira <omer_shapira at apple.com> wrote:
> 
> 
> 
>> On Oct 20, 2021, at 3:54 AM, Michael Welzl via Rpm <rpm at lists.bufferbloat.net <mailto:rpm at lists.bufferbloat.net>> wrote:
>> 
>> 
>> 
>>> On 20 Oct 2021, at 12:44, Toke Høiland-Jørgensen <toke at toke.dk <mailto:toke at toke.dk>> wrote:
>>> 
>>> Michael Welzl <michawe at ifi.uio.no <mailto:michawe at ifi.uio.no>> writes:
>>> 
>>>>> On 20 Oct 2021, at 11:44, Toke Høiland-Jørgensen <toke at toke.dk <mailto:toke at toke.dk>> wrote:
>>>>> 
>>>>> Michael Welzl <michawe at ifi.uio.no <mailto: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.
> 
> Yet, the QUIC protocol makes ACKs part of the protected payload. Having the ACKs protected by the frame protection allows ensuring that nobody had meddled with the ACKs - and by this to avoid an entire class of attacks that put a close-by endpoint which NACKs segments.

Were such attacks a real problem before QUIC was designed?  And besides, aren’t MASQUE proxies visible and authenticated?


>> 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.
> 
> 
> Michael, it sounds to me that what you are describing is something that belongs to the datalink layer (LL or MAC), maybe with an addition of namespaces (at the MAC layer) which can be aligned with the streams / connections. However, once we get into QUIC, the assumption that we are free to meddle with the ACK frames is problematic.

I know it is, but I doubt that this is good design. Here you have an enforced inability for cross-layer interaction (which could be done nice and clean, with a vertical interface) due to the enforcement of e2e transport, with everything encrypted. This connects to the question in another email:


>>> 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?
> 
> Can you elaborate? 

If I understood it correctly, MASQUE will (always? I’m not sure) maintain an end-to-end connection including encryption of headers, preventing ACKs, and preventing the division of congestion control at the proxy. I’m certain that this poor design, especially since MASQUE proxies are not transparent - so why not trust them to do these things right?

Yet, I’m also quite convinced that trying to argue against any of the security mechanisms in QUIC will make me age faster, and I cherish the years that I still have left  :-)

Anyway, if mmWave links become more prevalent at some point in the future, I’ll be happy that we still have TCP as well. Already, I’ve seen presentations of e.g. satellite systems working better with TCP than with QUIC due to the proxying capability… is this a big surprise?  As LL capacity fluctuations become more prevalent, and grow in magnitude, e2e mechanisms will become worse.

Cheers,
Michael

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/rpm/attachments/20211021/cf40404e/attachment-0001.html>