Re: Two Notable Ack Frequency Issues

Ian Swett <> Tue, 14 September 2021 17:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3F6C83A26CF for <>; Tue, 14 Sep 2021 10:39:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -18.097
X-Spam-Status: No, score=-18.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.499, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3Kv8lPtf6g5J for <>; Tue, 14 Sep 2021 10:39:21 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::b2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 670983A26D0 for <>; Tue, 14 Sep 2021 10:39:21 -0700 (PDT)
Received: by with SMTP id y13so30076429ybi.6 for <>; Tue, 14 Sep 2021 10:39:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vv3xQfqXh2SMSl9y8bM3loD6u2f5uxbyUx61mFxgt+0=; b=OHPzWBVHa6rFnC5ERGZ5+mVDvSj8Ixzfbnu+Solj0Xz1i1996S6ouyq9DnPRtsn4KY D9pH32/JvlmHdj8k3DAtat0kAGLI8Bhc34lToYt0WYIFZN5LXR3p8u/LEOqSIbCEEKrb b5XcKlMilpW4NEDkKVuXATMLj9r8ObfK4uQEmmIsemWXDSAh7Tc+bT3wQGXvQAtl461f N3KaIaNlrahBLLdfrVVecWrJOUJZEHXfwcy2D4OQHYBck966Uy93mmousZnhrhWyU485 0eTik8XGRmkeyNvj2ayuPU578mGR2Pf4iaXxNoj0u6rOvpN6HqsERhH3XPUdngT2rWYH pn6g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vv3xQfqXh2SMSl9y8bM3loD6u2f5uxbyUx61mFxgt+0=; b=iUE7WB5lfOzgYGcExK6rJegD3G3QUrmn88luzT54JQI49XwjpxdboL4sgrp36klQ7g kroOIWBDseODAggKinJccIuVRQGdIyVmqv0fW8NwLR8DprMqJ2SVaOfUTdzYHz0mA2o9 cpC8CMYmBZCQi8C4bRMOHE42aeELs+1TkN8wwyfc4xRN3KWFxVdGkSMVrWj66PXTdY75 CsrMwy1N8Qsfty2NzErRg4PJBiFszLDqedDec0ylwWxUNphIKUR43VjBLJKj/he3/xaG msM0wEQ4hcvRiQpNcXkU4x2ZDWXA5efRi1TwMvE6n2EVGQiMDC5cqT20hlupUiCFCiFX 32tw==
X-Gm-Message-State: AOAM531Cj+B6izwOpxIfiXAdK8BVHZfVnJm4gwd77GKjV+bf3RwR8oxS afA6VsSuUQ62RE8KN4wIahQq2GF+tzr/VpcAAmBdtTwAV58=
X-Google-Smtp-Source: ABdhPJzo1hk8trW38WKJvQnKdjY3CtfLmY5ObYxTLwWoDhN+BKAoiD+zsBIfVTNXwCiUrrURnj0JJbx0SDdI+6VE03c=
X-Received: by 2002:a25:3002:: with SMTP id w2mr439464ybw.76.1631641158922; Tue, 14 Sep 2021 10:39:18 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <>
In-Reply-To: <>
From: Ian Swett <>
Date: Tue, 14 Sep 2021 13:39:07 -0400
Message-ID: <>
Subject: Re: Two Notable Ack Frequency Issues
To: Martin Thomson <>
Content-Type: multipart/alternative; boundary="000000000000ae53cc05cbf80fd5"
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 14 Sep 2021 17:39:27 -0000

Thanks for the continued feedback.  I'm going to abandon DELAY_ACK for now
and let it or a similar mechanism go into a separate draft at some point in
the future.

I'll focus on the ECN issue and PR, in hopes of getting that into good

Thanks, Ian

On Mon, Sep 13, 2021 at 11:41 PM Martin Thomson <> wrote:

> On Tue, Sep 14, 2021, at 12:04, Ian Swett wrote:
> > I've substantially changed my PR on NO_ACK to be DELAY_ACK.
> I'm not sure that I understand this change.  The PR reads:
> > The DELAY_ACK Frame causes the receiver to send an immediate
> acknowledgement,
> Is that missing a negation somewhere?
> If I'm guessing correctly, what you want to say is that this packet should
> start the delayed acknowledgment timer if it is not already started, but
> not be cause for an immediate acknowledgment.  That is, no immediate
> acknowledgment is generated even if this packet causes the number of
> unacknowledged packets to hit the Ack-Eliciting Threshold or it appears out
> of order and Ignore Order is not enabled.
> This effectively disables both the Ack-Eliciting Threshold and a setting
> of Ignore Order = 0.  Only the timer remains.  That might be safer than
> completely disabling acknowledgment, but I think my previous position
> stands on this.
> > On IMMEDIATE_ACK, it both solves a clear problem
> I can see how IMMEDIATE_ACK works (I had forgotten previous discussions
> and the linked discussion is a little thin).  I'm OK with defining a frame
> for this purpose.
> FWIW, this is better than packet number skipping (which was always a
> kludge).