Re: Two Notable Ack Frequency Issues

Christian Huitema <> Mon, 13 September 2021 00:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D517C3A0B6E for <>; Sun, 12 Sep 2021 17:28:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.891
X-Spam-Status: No, score=-1.891 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Xpv5HY9qT3cW for <>; Sun, 12 Sep 2021 17:28:13 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A94F73A0B6D for <>; Sun, 12 Sep 2021 17:28:13 -0700 (PDT)
Received: from ([] by with esmtp (Exim 4.92) (envelope-from <>) id 1mPZpQ-00014k-2g for; Mon, 13 Sep 2021 02:28:09 +0200
Received: from (unknown []) by (Postfix) with ESMTPS id 4H76l871pSz4mx for <>; Sun, 12 Sep 2021 17:28:04 -0700 (PDT)
Received: from [] ( by with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <>) id 1mPZpM-0000I1-Ro for; Sun, 12 Sep 2021 17:28:04 -0700
Received: (qmail 19377 invoked from network); 13 Sep 2021 00:28:04 -0000
Received: from unknown (HELO []) ([]) (envelope-sender <>) by (qmail-ldap-1.03) with ESMTPA for <>; 13 Sep 2021 00:28:04 -0000
References: <> <>
From: Christian Huitema <>
Subject: Re: Two Notable Ack Frequency Issues
Message-ID: <>
Date: Sun, 12 Sep 2021 17:28:04 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
Authentication-Results:; auth=pass smtp.auth=
X-Spampanel-Outgoing-Class: unsure
X-Spampanel-Outgoing-Evidence: Combined (0.15)
X-Recommended-Action: accept
X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT9WLQux0N3HQm8ltz8rnu+BPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5x6h2yQpzTslcOqazQkKtAFKj/EwzSHE5FGYwwjsNRPCIcR z1HV0LTfI2mtndoSbFPmD6wdmZPcItWbGe10hXJtXL4FsauCVkDjmcYJdU3yWp7KuHNaaKdg7iBE ZefdsNUFWKwa/wzJUjmazeC7ImcaqlHdH9stIYSUOP2ajLGtTxQ6V51u76v35b1wNe/MvdKAGdwU TZKlze5ERymXAD3v2+J9PgaoF8SQHto3le4zsHTaeQtlKubP6iUTjj6yPARK6buALVaA782LKxg6 vRmng8N1aLhXqdc+jC1RcnVud53D5caUhbVtvqItBqoizkEt9O20UjkwI0v+LOlw05G4BS+iyyNq bT8dUMXMJ4tUCMj6G37ZfAMLceP5aNHPt26RBupu5v1nytoNnc138GfEJRQ2qC7jjynPIHPNqSn4 QTXUjLjYWQt1/5xnQymMoPsgr/U0flMcy2Vi/IcBgY4arPaiJ1W6hAyiRC61jekdwIcXNugoOEbH RyFULpSjm7jZ1h/HfDRQ5Ig8VhPsPE8NaP2gA77cO7WeI9Ftai6fuujlkzzl8Zr1hwu7lOvlZws6 XLaWVKjBQEGJ8KyWcCYIDRojSVizNl0ce/s7u0P9b9Tml6eOMCV9kYYwkPx6ZsXvIUzTXkDAiiJi mGhLUFuSW8D9t0kz0vlag+LRt89q4A7ZkYxFRynz9LbGtjHqVTqyuLfHqAnAj7rgKH7+eCmmq1C5 iQytrptCC8vB+/7ey1ShcA6Xvva2QAVEjpqzANap+28aWyCRVT7YkY7LckVctLtsOuYgMYQNsmxq 6b9Olr13qFZSq8Fx+9otn0aqja8VKPqpdskk5LxBR/9t1zMMkdu6/R2FM84kxYRFSvC1IDg1BRW7 hzp8w3iHcOwbVtsmWfnQGGis4EvbR3jXsI0ESXwhBU2hwt/J18C+HygJl/jEzm1SsR8v3aJbN/NZ fa8pHhHaz+HPa0HAgEx4sWDF
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:28:19 -0000

I left a comment on the NO_ACK issue and PR.

I don't think this solves a real issue, and I do think it could turn out 
to be an interesting footgun, as in "packet 1, don't ack; packet 2, do 
ack; oops, packet 2 was lost, let's repeat both 1 and 2." Also, if a 
packet carried both "immediate ack" and "don't ack", my preference would 
be to return a protocol error, not try to second guess a meaning. Plus, 
suppose an implementation just ignores the "don't ack" frames. What is 
the effect on the protocol?

-- Christian Huitema

On 9/12/2021 4:59 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