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

[Michael Welzl]

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

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