Re: Two Notable Ack Frequency Issues

Matt Joras <> Mon, 13 September 2021 00:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 784873A0C67 for <>; Sun, 12 Sep 2021 17:50:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 h6B-FfXSFRLq for <>; Sun, 12 Sep 2021 17:50:44 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6008E3A0C63 for <>; Sun, 12 Sep 2021 17:50:44 -0700 (PDT)
Received: by with SMTP id y6so14143776lje.2 for <>; Sun, 12 Sep 2021 17:50:44 -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=K23DLgxwEzIkB6ErHQOpXEXiUY0vTCDQUU0/mettLZA=; b=pRmR85OEAZ/Yx5EdF1qh3CpIz4PDRSswpJBmTqQFlCtzXTYThap1u6RXBOSQvimV7c VbfY85BIBlBMPWghRoGe0ncKQHxpnHUEiOhMjhNU2e0d/J9qBNInhdatnzWOewuDb9hm 4EarnSFs9yWrwgB+u3J4v/DSmeAbMuMH7jKc3CxWtWELT0rNmaQiJdfhmrGlTWAS7SCa lusfdW+yLuAJqo0GTHz7OOn71W2iK/3MWJ86msEzHsLKmN3Orn8S+78RrEadVbGVljE8 tCwOGAE6mQRJc9JCIJ6FdPtwU1p04ypYCiPqsh797/lFaKdImO32aBUgmVcYLj6g9H6D hJVg==
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=K23DLgxwEzIkB6ErHQOpXEXiUY0vTCDQUU0/mettLZA=; b=rTKPS3EGutzHjYMC/DLwOn6E+p1Z8oYuwV4feyiK3uULgjFVOKwDbKKfYOIFw5JSnC kmVzIgAD5rv0MUwFGzFBdEPmOAxx4fHTlFMXpV9TABXQMg+39GOJBIw/dowoOeW1m8/G adrcef1+h2NOaugnWvpJgodZI3kK4SWwoleHPrelbHcfeYrcLRA07/Z2Vr3uSiXI7f7X g2/s/8W7N2pN9H3FiTecuX6jcuj/bQerfT8VgepUTqChX+5Krzi0NDHPbgZ/P4l3gGHb dUq61neaHgGF1bTeLt4NedoxsDk60eeVEkJmT4OLE7Em4kNT6emMfhdfNGyRaD0LFArs fdQg==
X-Gm-Message-State: AOAM531JwzVDy/LHVzbJecbzIjKFTFmS8EcLYX0ajd54ray3dKL1vjcn vOcqMHOdJQ356ttSo1wkP1YfHJrKXjeIxiFYDVD+ZwsejXU=
X-Google-Smtp-Source: ABdhPJzweqmUffLFFZKGFgBfJLn50Sx4bzcXa2BMBRQ9bXIGy3KgfUjnidbf/gcmzHWUajShgVTZCQuRUJLaj6Ocw+k=
X-Received: by 2002:a2e:89c9:: with SMTP id c9mr8316338ljk.107.1631494241396; Sun, 12 Sep 2021 17:50:41 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Matt Joras <>
Date: Sun, 12 Sep 2021 17:50:30 -0700
Message-ID: <>
Subject: Re: Two Notable Ack Frequency Issues
To: Martin Thomson <>
Content-Type: multipart/alternative; boundary="000000000000b62a8d05cbd5dac4"
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: Mon, 13 Sep 2021 00:50:50 -0000

Speaking as an individual. There may not have been any list discussion
about IMMEDIATE_ACK, but the idea (without that particular label) has been
discussed since we were still meeting in person. It is a relatively
straightforward idea which has also been explored for TCP[1]. It makes a
lot of sense to have this mechanism in the same document which introduces a
mechanism to control ACK frequency, as it allows the sender to potentially
mitigate some of the issues with reducing ACK frequency.

As for NO_ACK, I think it is best considered in the context of the related
issue[2] in the DATAGRAM draft. That is the driving usecase for the frame
at the moment, AFAIK. There are obviously a lot of considerations when
effectively disabling ACKs in QUIC, but these considerations are
considerably diminished when used with non-retransmitted application data
like DATAGRAMs (which may well be using application-layer congestion
control instead of QUIC congestion control as well). As I mentioned on the
issue, I am supportive of the feature for the simple reason that it will
enable existing UDP datagram applications to transition to QUIC datagrams
with minimal changes to the amount of data on the wire. This problem could
be solved with a DATAGRAM_NO_ACK frame introduced by a new draft, but that
has other considerations. I don't feel strongly that this needs to be in
this document, but clearly there is a need for a mechanism to selectively
limit ACKs.


On Sun, Sep 12, 2021 at 5:00 PM Martin Thomson <> wrote:

> The first seems benign.
> The second is pure scope creep and I'm opposed to adding it (as I am
> opposed to IMMEDIATE_ACK, which has not been discussed on the list thus far
> from what I can see, though that is less objectionable).  The discussion
> that is available really doesn't motivate it more than "that might be
> nice".  I would have expected a lot more discussion about what this is
> supposed to achieve, how an endpoint might decide that it is necessary to
> use the feature, under what conditions it might be inadvisable, precedence
> (NO_ACK > IMMEDIATE_ACK: why?), and probably some other stuff I haven't
> thought of yet.
> On Sun, Sep 12, 2021, at 09:50, Ian Swett wrote:
> > Most of the outstanding design issues were discussed at the last IETF
> > meeting and had clear resolutions.  As such, I think we're close to
> > being ready to ship this draft.
> >
> > One issue not discussed(#48
> > <>) regarding ECN CE
> > and a new issue(#65
> > <>) adding a NO_ACK
> > frame are notable changes and have not received wide discussion, so I
> > wanted to publicize them here before merging any changes.
> >
> > I think both changes are heading in the right direction, and both have
> > PRs you can comment on.
> >
> > I'd like to merge these in a week or so if there's no pushback, so
> > please take a look when you have time.
> >
> > Thanks, Ian