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

[Omer Shapira]

> On Oct 20, 2021, at 3:54 AM, Michael Welzl via Rpm <rpm at lists.bufferbloat.net> wrote:
> 
> 
> 
>> 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.

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.

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

> 
> Cheers,
> Michael
> 
> _______________________________________________
> Rpm mailing list
> Rpm at lists.bufferbloat.net <mailto:Rpm at lists.bufferbloat.net>
> https://lists.bufferbloat.net/listinfo/rpm <https://lists.bufferbloat.net/listinfo/rpm>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/rpm/attachments/20211020/b0417393/attachment-0001.html>