Re: [tcpm] Seeking WG opinions on ACKing ACKs with good cause (was: Possible error in accurate-ecn)

"Scheffenegger, Richard" <> Fri, 19 March 2021 09:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 301753A07DD for <>; Fri, 19 Mar 2021 02:17:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bp26nY3QqN2i for <>; Fri, 19 Mar 2021 02:17:20 -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 0C8073A07D7 for <>; Fri, 19 Mar 2021 02:17:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=badeba3b8450; t=1616145437; bh=CiBFxkljBFDXge4L07NqlLDUhdWn3ToC/4PiKBejiXk=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=QTMQUDNSw+bLklb4KJ6TFFEEtOMXdZxCO8g6QrtxC14i/mNcgUHtpybRjZIumy41X 7kEa1IILfV46ij/2FO4rLSqL0f7mVkNSfC2bIKTtiql10qmTnA1fEXiW7ykVDqNp+6 ZPuIFp2cPn8sbMhLbm7wef4YTCQ0NYbOmthd1m1o=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [] ([]) by (mrgmx005 []) with ESMTPSA (Nemesis) id 1Ml6qM-1m6MuP1Tsi-00lRP4; Fri, 19 Mar 2021 10:17:17 +0100
To: Jonathan Morton <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: "Scheffenegger, Richard" <>
Message-ID: <>
Date: Fri, 19 Mar 2021 10:17:15 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:hjCczvT4GDvRI/vQwupgxlyY2SL0Pa+5xhCFgKVEB2fu7nFk6fn du6NsioreWknkG6Kfh8whdcA/+1pbWJqUlWDCssgjNmF85ukmBzL+X7XixPK7EWLj9u9Mml Ns38V0iIYZIDQ7PY0bEZ/1VaMA6ETLYyMkwdP/M9vlCtW56CveH1O7TKX8HuUqG2P82Ygm/ X64+yl8Mr3n4nm1VNCuHQ==
X-UI-Out-Filterresults: notjunk:1;V03:K0:MFqB8S9n4m8=:+wzq3WvND+D28O2yqPzPf/ liZQDAwqmTJTGhRdjZN8z/GqyrpkHjM3E6+7R8VWNSQGKY7pdh2JFTmc4lxvDiu4NwiwOZ1Oe oSp04++Rmf8cAdDZ3WiTsqhOcMYPM5S4gj8UGeAvpnplQVjZZZLQpS+iSfZNKuUM9W8DxDlJt SgEmR/b+Fr25KqH+A82GmE2j4e9BXT3WbTM+m9xcCRMWYITPB/TOgEzPBwaGnulMqy7k0KEj0 4Vg5UtKsoCtDBzJ82KfZ6vc9sOnafVwZn0c4j5F4D1nLbg9aYPp80wigPvfV11KczDSfbic7e +kibEuDB555ffOjIFTKdCnGZqwnDjtgyljMzZ76+nB9kvaA6+NmNQVumzjt6p/jz41jUDVxDW fuPjWk2NNOsuHiutehUIyLQOPD+KxBXLlj5/kAsVX2tW9hOfTQDrdrpFpFgP/GuL40f2mqM9E /TcdtW5+m0aPYTI7iVpH+or6v3Q2uIRna3hsNq8h6GLWyPkf7tghsI1xjNVuU23SHrtaFTdiV E59AqW6KKKqsSbYwP+QVOKBrXXw5FjVsUFBhpKkn4JhQ4YlsTXvDeLBKhgw/wfITXkfq6Xtzq 7BA6ShrJKWMckQwr6Wzo3sQMQUyBv/lTfI4FYByTMEfBk5kmWHdcmDBzAglHLNd2Wv78/qDiJ rk5L9oYUSiQzAGhyQYR2RNuK+pwnpJnELhWxcOdzpNl9p6Dmj5plsY9YbusgFQ2VMwIqFn1aI y8hX+7tglvmhTWx7xqN3T3FOYSoH95hyExlVaGgjDJNAVgLnYwEMHo5rwvlYpJaEfEEXL9ujy srEs3n86uuiHSR4/8vgW6uosdcJpulJmDl2a2jzhi/vNIAk7Uk+eoBW7FgHunAFzZJGzgkuK5 5O0GJzjOsJ4QdHU9yQvg==
Archived-At: <>
Subject: Re: [tcpm] Seeking WG opinions on ACKing ACKs with good cause (was: Possible error in accurate-ecn)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 19 Mar 2021 09:17:22 -0000

Thank you Jonathan!

Your argument that this effect has to be considered to be a valid
(hopefully) temporary one is understood.

Am 19.03.2021 um 05:27 schrieb Jonathan Morton:
> - When the receiver of a CE-marked pure ack *does not* have data to send, it must either generate a pure ack to carry the notification, or store the notification for some future opportunity.
> - The former choice can be described as "acking an ack", and can lead to an infinite series of ack-acking exchanges if all such acks are CE marked in the network, and no mechanism for ending the exchange is specified.
> - Additionally, if the sender of an ECN-Capable pure ack subsequently has data available to send, and does so in more than one segment, a subsequent notification of a CE mark on the ack could be misinterpreted as a DupAck indicating possible loss of the data segment, combined with a CE mark on the second segment or later.
> The latter two points are what we need to evaluate, and guard against to the extent deemed necessary.
> One very simple method of breaking the infinite chain of notifications would be to specify that acks of acks should themselves be Not-ECT.  These will never be CE marked (modulo broken middleboxes).  Another is to require at least two outstanding "pure ack" CE marks before a pure ack can be generated as a notification; this does not preclude immediate notification of CE marks either upon or via data segments.  The latter method would guarantee an exponential decay of the volume of acks exchanged per RTT, and eventually halt them entirely.

This is already in the text (one ACK at most as often as every other
CE-mark received, as a MUST).

One proposal (maintaining the CE-mark feedback in these situations) was
to change the exponential decay factor, by sending out one
ACK-for-CE-ACKs only after a cumulative change of at least 3 counts (not
just two).

An additional (implementation specific) heuristic would be to send out
the ACK for n with the receipt of the n+1'th marked ACK, while priming
the delayed ACK timeout for sending a ACE counter change - improving the
chances that this information can be sent along with new data somewhat.

> I would recommend language specifying that one of the above methods, or some equivalently effective protection, SHOULD be implemented.

> I would recommend language stating that ECN-Capable pure acks SHOULD NOT be generated unless either TCP Timestamps or TCP SACK has been successfully negotiated on the connection, or some equivalent disambiguating information is available, AND that disambiguating information is actually used to prevent spurious retransmissions.  Since both Timestamps and SACK are in common use, that shouldn't be onerous.

Not ECT-marking these ACKs-for-CE-marked ACKs is actually an alternative
we (authors) haven't thought about, actually. For flows not doing either
SACK or Timestamps, that may be another SHOULD recommendation to include.

> However, it is also true that a spurious retransmission on occasion is probably not very harmful.
>   - Jonathan Morton