From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-out04.uio.no (mail-out04.uio.no [IPv6:2001:700:100:8210::76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id BE4C53B29E; Thu, 21 Oct 2021 04:42:44 -0400 (EDT) Received: from mail-mx11.uio.no ([129.240.10.83]) by mail-out04.uio.no with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1mdTel-00GYKX-65; Thu, 21 Oct 2021 10:42:35 +0200 Received: from ti0182q160-6611.bb.online.no ([95.34.115.34] helo=[192.168.1.7]) by mail-mx11.uio.no with esmtpsa (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.94.2) (envelope-from ) id 1mdTek-00056k-1U; Thu, 21 Oct 2021 10:42:35 +0200 From: Michael Welzl Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_53DB5488-7596-4EA3-B439-2A5D8967C172" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Date: Thu, 21 Oct 2021 10:42:32 +0200 In-Reply-To: Cc: Omer Shapira , Rpm , Make-Wifi-fast To: Keith Winstein References: <4BD0AC02-62FB-4AE4-B83B-BAF5CCEA2B24@ifi.uio.no> <87lf2of2sl.fsf@toke.dk> <09884015-6428-4402-BE61-9091006D1FB8@ifi.uio.no> <87ee8gf013.fsf@toke.dk> <9C553AC1-B470-4887-B770-9FD23D586889@apple.com> <178233EF-5125-415E-9D05-A25729FC1413@ifi.uio.no> X-Mailer: Apple Mail (2.3608.120.23.2.7) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx11.uio.no: 95.34.115.34 is neither permitted nor denied by domain of ifi.uio.no) client-ip=95.34.115.34; envelope-from=michawe@ifi.uio.no; helo=[192.168.1.7]; X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, UIO_MAIL_IS_INTERNAL=-5) X-UiO-Scanned: A659B5507483557115F68C1FBA461DCEEB88E2AE Subject: Re: [Rpm] [Make-wifi-fast] tack - reducing acks on wlans X-BeenThere: rpm@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: revolutions per minute - a new metric for measuring responsiveness List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2021 08:42:44 -0000 --Apple-Mail=_53DB5488-7596-4EA3-B439-2A5D8967C172 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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 = wrote: >=20 > 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). >=20 > 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=E2=80=99s 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

, and I'm = ACKing the datagram you sent to destination that had public ID . = I promise I will deliver that datagram soon to destination . 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 =E2=80=A6. either = way, I think we agree on =E2=80=9CThe endpoints can now decide what to = do with this extra info.=E2=80=9D 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=E2=80=A6 = 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=E2=80=99re = discussing here (AP ACK=E2=80=99ing 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 --Apple-Mail=_53DB5488-7596-4EA3-B439-2A5D8967C172 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 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=E2=80=99s 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 =E2=80=A6. either way, I think we = agree on =E2=80=9CThe endpoints can now decide what to do with this = extra info.=E2=80=9D  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=E2=80=A6 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=E2=80=99re discussing here (AP ACK=E2=80=99ing 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

    = --Apple-Mail=_53DB5488-7596-4EA3-B439-2A5D8967C172--