From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.cs.Stanford.EDU (smtp1.cs.stanford.edu [171.64.64.25]) (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 C84403CB38; Thu, 21 Oct 2021 16:19:59 -0400 (EDT) Received: from mail-oi1-f177.google.com ([209.85.167.177]:40587) by smtp1.cs.Stanford.EDU with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1mdeXd-0003kH-MK; Thu, 21 Oct 2021 13:19:58 -0700 Received: by mail-oi1-f177.google.com with SMTP id n63so2358614oif.7; Thu, 21 Oct 2021 13:19:57 -0700 (PDT) X-Gm-Message-State: AOAM532y8GiEM/uqCWzyc7JvUlPSb6MIo0RhHs6tBuxoWfbyNr7yXm86 S+qLuqWHhUl2SqLFU8hq4p4KqQ1zZgSuIPmZkw== X-Google-Smtp-Source: ABdhPJzfgu1FwWPsFFOgIw8D2+nWbih8XfzXJhF1TKJcLYzjT7XU7hGR3LFfc+8T/ywg5yqyK4ze4K+r/3z5gI2TuQs= X-Received: by 2002:aca:3741:: with SMTP id e62mr6623238oia.107.1634847597289; Thu, 21 Oct 2021 13:19:57 -0700 (PDT) MIME-Version: 1.0 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> In-Reply-To: From: Keith Winstein Date: Thu, 21 Oct 2021 13:19:19 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Michael Welzl Cc: Omer Shapira , Rpm , Make-Wifi-fast Content-Type: multipart/alternative; boundary="0000000000004c680305cee29e8e" X-Spam-Score: -1.0 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin on smtp1.cs.Stanford.EDU X-Scan-Signature: dfe9a19d2d5d3f4658608889c96f7beb X-Mailman-Approved-At: Sat, 23 Oct 2021 17:47:33 -0400 Subject: Re: [Make-wifi-fast] [Rpm] tack - reducing acks on wlans X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2021 20:19:59 -0000 --0000000000004c680305cee29e8e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 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 disca= rd > 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 ex= tra info.=E2=80=9D > 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 --0000000000004c680305cee29e8e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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 bel= ow...

On Thu, Oct 21, = 2021 at 1:42 AM Michael Welzl <michawe@ifi.uio.no> wrote:
Hi Keith !=
  • Prot= ocol 1: The endpoints can now decide what to do with this extra info. For e= xample, they could decide that the endpoint receiver should switch to super= delayed ACKs itself (maybe one every N seconds or M megabytes), and the se= nder will trust the Protocol 2 ACKs for congestion-control and retransmissi= on purposes, while still using the Protocol 1 ACKs for ultimate reliability= . (I.e. the sender won't discard outstanding data from a reliable strea= m 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 =C2=A0There can be many variation= s.

=C2=A0My thinkin= g here was that ACKs serve at least three different purposes in an ARQ-styl= e transport protocol:
  1. congestion control
  2. loss det= ection and triggering retransmission of previously sent data (via timeout, = dupacks, sender-side timestamp schemes (Sprout/RACK), etc.)
  3. gua= ranteeing the abstraction of a reliable byte stream, by making the sender r= etain a copy of the outstanding data (ready for possible retransmission) un= til ACKed by the receiver
I think most endpoints might be wil= ling to delegate #1 and #2 to an untrusted intermediary that's along th= e network path and eager to help (it's no worse than a transparent TCP = accelerator today), especially if there's some ability for the endpoint= s to double-check the intermediary's work and say, "you know what,= no thanks" if unsatisfied.

But #3 feels diff= erent -- 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 f= rom that without escalating to the application. So the sender probably shou= ldn't discard data irreversibly until it hears a cryptographically auth= entic ACK from the E2E receiver, but that could come much later and less fr= equently.

-Keith
--0000000000004c680305cee29e8e--