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

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

[Dave Taht]

Somehow I'd missed this paper... thx for the steer, keith.

https://cs.stanford.edu/~keithw/tack-sigcomm2020.pdf

-- 
Fixing Starlink's Latencies: https://www.youtube.com/watch?v=c9gLo6Xrwgw

Dave Täht CEO, TekLibre, LLC

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

[Matt Mathis]

[-- Attachment #1: Type: text/plain, Size: 877 bytes --]

Yes, a very cool paper!

Consider approaching the QUIC people, in principle they have more
agility to make protocol changes.

Thanks,
--MM--
Evil is defined by mortals who think they know "The Truth" and use force to
apply it to others.
-------------------------------------------
Matt Mathis  (Email is best)
Home & mobile: 412-654-7529 please leave a message if you must call.



On Tue, Oct 19, 2021 at 1:12 PM Dave Taht via Rpm <rpm@lists.bufferbloat.net>
wrote:

> Somehow I'd missed this paper... thx for the steer, keith.
>
> https://cs.stanford.edu/~keithw/tack-sigcomm2020.pdf
>
> --
> Fixing Starlink's Latencies: https://www.youtube.com/watch?v=c9gLo6Xrwgw
>
> Dave Täht CEO, TekLibre, LLC
> _______________________________________________
> Rpm mailing list
> Rpm@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/rpm
>

[-- Attachment #2: Type: text/html, Size: 1946 bytes --]

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

[Omer Shapira]

[-- Attachment #1: Type: text/plain, Size: 1601 bytes --]

Matt, Keith, Dave

I happen to be one of the "QUIC people." I’ll take a look and see what we can do about it.

Shameless plug: my team, which builds the transport protocols at Apple for the entire range of the OSes is hiring. 

Omer

> On Oct 19, 2021, at 1:25 PM, Matt Mathis via Rpm <rpm@lists.bufferbloat.net> wrote:
> 
> Yes, a very cool paper!
> 
> Consider approaching the QUIC people, in principle they have more agility to make protocol changes.
> 
> Thanks,
> --MM--
> Evil is defined by mortals who think they know "The Truth" and use force to apply it to others. 
> -------------------------------------------
> Matt Mathis  (Email is best)
> Home & mobile: 412-654-7529 please leave a message if you must call.
> 
> 
> 
> On Tue, Oct 19, 2021 at 1:12 PM Dave Taht via Rpm <rpm@lists.bufferbloat.net <mailto:rpm@lists.bufferbloat.net>> wrote:
> Somehow I'd missed this paper... thx for the steer, keith.
> 
> https://cs.stanford.edu/~keithw/tack-sigcomm2020.pdf <https://cs.stanford.edu/~keithw/tack-sigcomm2020.pdf>
> 
> -- 
> Fixing Starlink's Latencies: https://www.youtube.com/watch?v=c9gLo6Xrwgw <https://www.youtube.com/watch?v=c9gLo6Xrwgw>
> 
> Dave Täht CEO, TekLibre, LLC
> _______________________________________________
> Rpm mailing list
> Rpm@lists.bufferbloat.net <mailto:Rpm@lists.bufferbloat.net>
> https://lists.bufferbloat.net/listinfo/rpm <https://lists.bufferbloat.net/listinfo/rpm>
> _______________________________________________
> Rpm mailing list
> Rpm@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/rpm


[-- Attachment #2: Type: text/html, Size: 3492 bytes --]

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

[Michael Welzl]

Hi,

This is interesting indeed - though technically, I'd say it's the next best thing, a compromise that's needed because apparently this old ARQ proxy idea isn't deployable (or wasn't seen?):
https://orbilu.uni.lu/bitstream/10993/6555/1/arqproxy.pdf
This ARQ proxy removes all TCP ACKs over the wireless segment. It doesn't need to put the ACKs inside LL-ACKs like HACK (described in the TACK paper), and hence it doesn't need a change to NICs like HACK.  It just keeps track of incoming data packets and LL-ACKs, and takes care of L4 ACKing.

Now, the ARQ proxy needs a change to the AP, whereas the TACK idea (from a quick look) doesn't. That's a clear benefit of the TACK approach - changing less elements in the system. Also, the ARQ proxy as described in the paper above is probably transparent, which can cause ossification - but it won't need to be transparent.

I wonder: could someone standardize a negotiation between the (trusted, because the OS knows that this is indeed the AP) AP and the wireless end hosts, so that the AP can say: "I can ACK for you, please don't ACK"?
With this, in principle, it should be possible to completely remove L4 ACKs on the wireless segment, and this would be better for all.

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?

Cheers,
Michael


> On 19 Oct 2021, at 22:12, Dave Taht <dave.taht@gmail.com> wrote:
> 
> Somehow I'd missed this paper... thx for the steer, keith.
> 
> https://cs.stanford.edu/~keithw/tack-sigcomm2020.pdf
> 
> -- 
> Fixing Starlink's Latencies: https://www.youtube.com/watch?v=c9gLo6Xrwgw
> 
> Dave Täht CEO, TekLibre, LLC
> _______________________________________________
> Make-wifi-fast mailing list
> Make-wifi-fast@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/make-wifi-fast

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

[Toke Høiland-Jørgensen]

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 or other encrypted
transports (like VPNs).

-Toke

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

[Michael Welzl]

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


> or other encrypted
> transports (like VPNs).

Correct.

Cheers,
Michael

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

[Toke Høiland-Jørgensen]

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? In any case, it would require clients to negotiate
a proxy session with the AP and trust it to do that properly? 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?

-Toke

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

[Michael Welzl]

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

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.

Cheers,
Michael

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

[Sebastian Moeller]

Just reading the introduction:
"It is well-studied that medium acquisition overhead in WLAN based on the IEEE 802.11 medium access control (MAC) protocol [11] can severely hamper TCP throughput, and TCP’s many small ACKs are one reason [53, 69]. Basically, TCP sends an ACK for every one or two packets (i.e., received-packet-driven) [7, 15]. ACKs share the same medium route with data packets, causing similar medium access overhead despite the much smaller size of the ACK- s [8, 31, 36, 50, 58]. Contentions and collisions, as well as the wasted wireless resources by ACKs, lead to significant throughput decline on the data path (see §3.2)."

makes me wonder whether the proper solution would not be to exchange the WiFi MAC with something that is actually suited for existing traffic patterns.... 

On the other hand the Reno-ACK scheme is probably not really optimal today (if it ever was in the past) so improving transport-level feed-back schemes seems a worthy goal in itself.

But really, a packet network should be able to simply transport all packets reasonably efficiently..., no?

Regards
	Sebastian


> On Oct 19, 2021, at 22:12, Dave Taht via Rpm <rpm@lists.bufferbloat.net> wrote:
> 
> Somehow I'd missed this paper... thx for the steer, keith.
> 
> https://cs.stanford.edu/~keithw/tack-sigcomm2020.pdf
> 
> -- 
> Fixing Starlink's Latencies: https://www.youtube.com/watch?v=c9gLo6Xrwgw
> 
> Dave Täht CEO, TekLibre, LLC
> _______________________________________________
> Rpm mailing list
> Rpm@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/rpm

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

[Toke Høiland-Jørgensen]

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?

-Toke

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

[Toke Høiland-Jørgensen]

Sebastian Moeller <moeller0@gmx.de> writes:

> Just reading the introduction:
> "It is well-studied that medium acquisition overhead in WLAN based on
> the IEEE 802.11 medium access control (MAC) protocol [11] can severely
> hamper TCP throughput, and TCP’s many small ACKs are one reason [53,
> 69]. Basically, TCP sends an ACK for every one or two packets (i.e.,
> received-packet-driven) [7, 15]. ACKs share the same medium route with
> data packets, causing similar medium access overhead despite the much
> smaller size of the ACK- s [8, 31, 36, 50, 58]. Contentions and
> collisions, as well as the wasted wireless resources by ACKs, lead to
> significant throughput decline on the data path (see §3.2)."
>
> makes me wonder whether the proper solution would not be to exchange
> the WiFi MAC with something that is actually suited for existing
> traffic patterns....

Well, there are people who want to do that (replace the MAC); it's
called LTE-U: https://en.wikipedia.org/wiki/LTE_in_unlicensed_spectrum

I'd much rather keep the WiFi MAC, thankyouverymuch. It may suck (for
certain values of "suck"), but at least it doesn't impose a centralised
controller on you :)

-Toke

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

[Michael Welzl]

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

Cheers,
Michael

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

[Toke Høiland-Jørgensen]

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

-Toke

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

[Michael Welzl]

> 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  :)
But yes, whether it's worth it is questionable, of course; if TACK is good enough, it'll be easier to deploy of course.

Cheers,
Michael

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

[Sebastian Moeller]

Hi Toke,


> On Oct 20, 2021, at 13:55, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
> 
> Sebastian Moeller <moeller0@gmx.de> writes:
> 
>> Just reading the introduction:
>> "It is well-studied that medium acquisition overhead in WLAN based on
>> the IEEE 802.11 medium access control (MAC) protocol [11] can severely
>> hamper TCP throughput, and TCP’s many small ACKs are one reason [53,
>> 69]. Basically, TCP sends an ACK for every one or two packets (i.e.,
>> received-packet-driven) [7, 15]. ACKs share the same medium route with
>> data packets, causing similar medium access overhead despite the much
>> smaller size of the ACK- s [8, 31, 36, 50, 58]. Contentions and
>> collisions, as well as the wasted wireless resources by ACKs, lead to
>> significant throughput decline on the data path (see §3.2)."
>> 
>> makes me wonder whether the proper solution would not be to exchange
>> the WiFi MAC with something that is actually suited for existing
>> traffic patterns....
> 
> Well, there are people who want to do that (replace the MAC); it's
> called LTE-U: https://en.wikipedia.org/wiki/LTE_in_unlicensed_spectrum

	And here I thought their idea was to simply grab the "free" Frequency band and use them for their paid services.... 

> I'd much rather keep the WiFi MAC, thankyouverymuch. It may suck (for
> certain values of "suck"), but at least it doesn't impose a centralised
> controller on you :)

	Well, if the price for a more effficient MAC is a central controller, I guess trying to patch up the symptoms of the current MAC is a much better strategy than I gave credit for.... ;)

Regards
	Sebastian


> 
> -Toke

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

[Toke Høiland-Jørgensen]

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

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

[Anna Brunström]

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

Anna

När du skickar e-post till Karlstads universitet behandlar vi dina personuppgifter<https://www.kau.se/gdpr>.
When you send an e-mail to Karlstad University, we will process your personal data<https://www.kau.se/en/gdpr>.

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

[Omer Shapira]

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

Can you elaborate? 

> 
> 
>> or other encrypted
>> transports (like VPNs).
> 
> Correct.
> 
> Cheers,
> Michael
> 
> _______________________________________________
> Rpm mailing list
> Rpm@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/rpm

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

[Omer Shapira]

[-- Attachment #1: Type: text/plain, Size: 3011 bytes --]



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

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@lists.bufferbloat.net <mailto:Rpm@lists.bufferbloat.net>
> https://lists.bufferbloat.net/listinfo/rpm <https://lists.bufferbloat.net/listinfo/rpm>

[-- Attachment #2: Type: text/html, Size: 16434 bytes --]

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

[Michael Welzl]

> 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

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

[Michael Welzl]

[-- Attachment #1: Type: text/plain, Size: 4601 bytes --]



> On Oct 21, 2021, at 1:20 AM, Omer Shapira <omer_shapira@apple.com> wrote:
> 
> 
> 
>> On Oct 20, 2021, at 3:54 AM, Michael Welzl via Rpm <rpm@lists.bufferbloat.net <mailto:rpm@lists.bufferbloat.net>> wrote:
>> 
>> 
>> 
>>> On 20 Oct 2021, at 12:44, Toke Høiland-Jørgensen <toke@toke.dk <mailto:toke@toke.dk>> wrote:
>>> 
>>> Michael Welzl <michawe@ifi.uio.no <mailto:michawe@ifi.uio.no>> writes:
>>> 
>>>>> On 20 Oct 2021, at 11:44, Toke Høiland-Jørgensen <toke@toke.dk <mailto:toke@toke.dk>> wrote:
>>>>> 
>>>>> Michael Welzl <michawe@ifi.uio.no <mailto: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.
> 
> 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


[-- Attachment #2: Type: text/html, Size: 14287 bytes --]

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

[Michael Welzl]

[-- Attachment #1: Type: text/plain, Size: 1188 bytes --]

Hi again,

A clarification about one point here - I had overlooked “close-by”, now I think I understand the attack: this is a host on the same WiFi network, spoofing packets, and sending NACKs (or DupACKs, for TCP, probably) - right?

See below:

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

So this seems not to be a matching answer for the attack that I now think you have in mind.
Here’s another answer:  this is solved by encryption between the host and the MASQUE proxy. That’s okay, I’m not questioning this part of the design.  What I say is: the MASQUE proxy itself shouldn’t have to relay e2e-encrypted transport headers (which I *believe* it does, but I really still have some catching-up to do).  (and of course I also don’t speak against the e2e encryption of payload!)

Cheers,
Michael


[-- Attachment #2: Type: text/html, Size: 2368 bytes --]

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

[Keith Winstein]

[-- Attachment #1: Type: text/plain, Size: 4110 bytes --]

It seems like there is probably some design available that decouples (1)
the end-to-end encrypted transport protocol from (2) the optional network
assistance, and allows the two protocols to evolve semi-separately without
mutual trust (and giving the endpoints the option of whether or not to
react to volunteered network assistance).

E.g., just to sketch out a straw person:

   - Protocol 1: The end-to-end protocol defines a unique "public ID" for
   each datagram. This could be implicit, e.g. "the SHA256/64 hash of the
   encrypted UDP datagram," or QUIC could start exposing its Packet Numbers
   (authenticating them but not encrypting them).
   - Protocol 2: An intermediary that wants to volunteer assistance (e.g. a
   Wi-Fi AP) can send its own messages to either endpoint, ideally by
   appending them to the end-to-end payload for datagrams already in flight,
   or by generating and sending its own datagrams. These messages would be
   defined by a separate protocol spec and could evolve separately.
   - Protocol 2: You could imagine a useful message for protocol #2 might
   express something like, "I'm a Wi-Fi AP with public key <p>, and I'm ACKing
   the datagram you sent to destination <d> that had public ID <id>. I promise
   I will deliver that datagram soon to destination <d>. Do you want me to
   keep sending these?" (and maybe the endpoint is like, "Sure, keep sending
   those," or, "Not interested, please stop.")
   - Protocol 1: The endpoints can now decide what to do with this extra
   info. For example, they could decide that the endpoint receiver should
   switch to super delayed ACKs itself (maybe one every N seconds or M
   megabytes), and the sender will trust the Protocol 2 ACKs for
   congestion-control and retransmission purposes, while still using the
   Protocol 1 ACKs for ultimate reliability. (I.e. the sender won't discard
   outstanding data from a reliable stream until it's been ACKed by the
   endpoint.)
   - If the Protocol 2 ACKs seem to be lying about receiving something that
   never gets to the endpoint, the endpoints can detect this (since they still
   have occasional end-to-end ACKs) and decide never to trust the intermediary
   again and go back to previous behavior.

It would be nice not to give up the benefits of end-to-end authenticated
ACKs, while allowing intermediaries to provide most of the benefits we get
with TCP acceleration, and also without tightly coupling these protocols to
prevent them from evolving separately. I think it is probably possible, at
least for this kind of use case. But I don't think there's much of a will
to do this in practice; it's not something the major traffic sources seem
particularly interested in afaik.

-Keith

On Thu, Oct 21, 2021 at 12:18 AM Michael Welzl <michawe@ifi.uio.no> wrote:

> Hi again,
>
> A clarification about one point here - I had overlooked “close-by”, now I
> think I understand the attack: this is a host on the same WiFi network,
> spoofing packets, and sending NACKs (or DupACKs, for TCP, probably) - right?
>
> See below:
>
> 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?
>
>
> So this seems not to be a matching answer for the attack that I now think
> you have in mind.
> Here’s another answer:  this is solved by encryption between the host and
> the MASQUE proxy. That’s okay, I’m not questioning this part of the
> design.  What I say is: the MASQUE proxy itself shouldn’t have to relay
> e2e-encrypted transport headers (which I *believe* it does, but I really
> still have some catching-up to do).  (and of course I also don’t speak
> against the e2e encryption of payload!)
>
> Cheers,
> Michael
>
>

[-- Attachment #2: Type: text/html, Size: 5010 bytes --]

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

[Michael Welzl]

[-- Attachment #1: Type: text/plain, Size: 3939 bytes --]

Hi Keith !

I think you generally paraphrased pretty much what I have in mind - but with some important differences, see below:


> On Oct 21, 2021, at 9:57 AM, Keith Winstein <keithw@cs.stanford.edu> wrote:
> 
> It seems like there is probably some design available that decouples (1) the end-to-end encrypted transport protocol from (2) the optional network assistance, and allows the two protocols to evolve semi-separately without mutual trust (and giving the endpoints the option of whether or not to react to volunteered network assistance).
> 
> E.g., just to sketch out a straw person:
> Protocol 1: The end-to-end protocol defines a unique "public ID" for each datagram. This could be implicit, e.g. "the SHA256/64 hash of the encrypted UDP datagram," or QUIC could start exposing its Packet Numbers (authenticating them but not encrypting them).
Yes exactly, that’s a necessary first part.


> Protocol 2: An intermediary that wants to volunteer assistance (e.g. a Wi-Fi AP) can send its own messages to either endpoint, ideally by appending them to the end-to-end payload for datagrams already in flight, or by generating and sending its own datagrams. These messages would be defined by a separate protocol spec and could evolve separately.
The last sentence here is a big deviation from what I had in mind, and I find it *very* thought-provoking!

> Protocol 2: You could imagine a useful message for protocol #2 might express something like, "I'm a Wi-Fi AP with public key <p>, and I'm ACKing the datagram you sent to destination <d> that had public ID <id>. I promise I will deliver that datagram soon to destination <d>. Do you want me to keep sending these?" (and maybe the endpoint is like, "Sure, keep sending those," or, "Not interested, please stop.")
Yes; this matches the signaling I had in mind when I talked about explicit agreements to do this kind of function before.

> Protocol 1: The endpoints can now decide what to do with this extra info. For example, they could decide that the endpoint receiver should switch to super delayed ACKs itself (maybe one every N seconds or M megabytes), and the sender will trust the Protocol 2 ACKs for congestion-control and retransmission purposes, while still using the Protocol 1 ACKs for ultimate reliability. (I.e. the sender won't discard outstanding data from a reliable stream until it's been ACKed by the endpoint.)
Not sure I see the point of super delayed ACKs, but …. either way, I think we agree on “The endpoints can now decide what to do with this extra info.”  There can be many variations.


> If the Protocol 2 ACKs seem to be lying about receiving something that never gets to the endpoint, the endpoints can detect this (since they still have occasional end-to-end ACKs) and decide never to trust the intermediary again and go back to previous behavior.
As one possible implementation strategy, yes (this may depend on various things).


> It would be nice not to give up the benefits of end-to-end authenticated ACKs, while allowing intermediaries to provide most of the benefits we get with TCP acceleration, and also without tightly coupling these protocols to prevent them from evolving separately.

Again this view of protocol separation that I find so inspiring… many thanks for this!


> I think it is probably possible, at least for this kind of use case. But I don't think there's much of a will to do this in practice; it's not something the major traffic sources seem particularly interested in afaik.

Yes, but this may also be because the use case that we’re discussing here (AP ACK’ing instead of TACK) is probably weak: I really have no clue if it would be worth the extra effort and deployment hurdle. To begin with, if TACK resolves problems with ACKs on WiFi to a large enough degree, there may not be any notable benefit at all.  There may be other use cases.


Cheers,
Michael


[-- Attachment #2: Type: text/html, Size: 5890 bytes --]

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

[Keith Winstein]

[-- Attachment #1: Type: text/plain, Size: 2301 bytes --]

Hi Michael -- glad we are mostly of like mind! Let me try to explain where
I was coming from with the super-delayed E2E ACKs below...

On Thu, Oct 21, 2021 at 1:42 AM Michael Welzl <michawe@ifi.uio.no> wrote:

> Hi Keith !
>
>
>    - Protocol 1: The endpoints can now decide what to do with this extra
>    info. For example, they could decide that the endpoint receiver should
>    switch to super delayed ACKs itself (maybe one every N seconds or M
>    megabytes), and the sender will trust the Protocol 2 ACKs for
>    congestion-control and retransmission purposes, while still using the
>    Protocol 1 ACKs for ultimate reliability. (I.e. the sender won't discard
>    outstanding data from a reliable stream until it's been ACKed by the
>    endpoint.)
>
> Not sure I see the point of super delayed ACKs, but …. either way, I think
> we agree on “The endpoints can now decide what to do with this extra info.”
>  There can be many variations.
>

 My thinking here was that ACKs serve at least three different purposes in
an ARQ-style transport protocol:

   1. congestion control
   2. loss detection and triggering retransmission of previously sent data
   (via timeout, dupacks, sender-side timestamp schemes (Sprout/RACK), etc.)
   3. guaranteeing the abstraction of a reliable byte stream, by making the
   sender retain a copy of the outstanding data (ready for possible
   retransmission) until ACKed by the receiver

I think most endpoints might be willing to delegate #1 and #2 to an
untrusted intermediary that's along the network path and eager to help
(it's no worse than a transparent TCP accelerator today), especially if
there's some ability for the endpoints to double-check the intermediary's
work and say, "you know what, no thanks" if unsatisfied.

But #3 feels different -- if an untrusted intermediary's false ACK causes
the sender to delete its copy of data that never makes it to the receiver,
that threatens the core service model of the protocol. It's not possible to
recover from that without escalating to the application. So the sender
probably shouldn't discard data irreversibly until it hears a
cryptographically authentic ACK from the E2E receiver, but that could come
much later and less frequently.

-Keith

[-- Attachment #2: Type: text/html, Size: 2803 bytes --]