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

Jonathan Morton <> Tue, 30 March 2021 19:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7D8B73A2007 for <>; Tue, 30 Mar 2021 12:52:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.849
X-Spam-Status: No, score=-1.849 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 2xKFAvrrh9iC for <>; Tue, 30 Mar 2021 12:52:50 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5C7803A1FDD for <>; Tue, 30 Mar 2021 12:52:47 -0700 (PDT)
Received: by with SMTP id 12so15172215lfq.13 for <>; Tue, 30 Mar 2021 12:52:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=6Xn6rIf3NPaRBx6pvrch7fEmPBmFd4K1uv/jtnBQy88=; b=gvwX7WxFM7FMfJdtFPlTo3ZQnGRbYdDvOrJ1wlUv+yizPNdDSKb81n4e+HXkpeF/8M vhWC3CjNad+wTCHB7iUyUWzuAwMQjRlIBrA+2p40baNy+P0qHxVIitiMjzBIDDpbPB8d MVPsqIGkTZwIUvA1UuNUZ11JNcpKODjYLeYpO/3vSRw1nna6L90dOcwJHXznXIF1FcH/ wMDsgm5f+A9w4WacIo2jSeO4HlYYIKxDU80RFEFHwMkUYBAjrMBBKsgFAhq+WpCBw1/f 2nMlP6uAp4MDa5zqJJFeXbDhtOhU+sK3AkIJrpYUAPJ8cxxTpxWAjE/g0M0W1+6aymnW mplw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=6Xn6rIf3NPaRBx6pvrch7fEmPBmFd4K1uv/jtnBQy88=; b=EDHD9UxtU4NYW3oI+QRkg5PgR3k2wRf6ALWGJyzpXJC13Cg0d5/mtzKY08LKR2HnyD TCRBuROhmOfqlmBTjvGW9VnJi3HfdeWpK++8xNAc+hm+n+U5HnP9whBOM5mIVQOteT5B iw7eLTClmLHiyYiz/rVaH/RTZ3xB6CZm650qB6ktoLR6a66zqnAQoXTKMw1fZSyewft1 zXNVsNZR5Lxn3fj4lBwwhCGbSkO8OQF7pGit/FYvj1b1O59W/pD9oMGBCtN4i86mc3jj uM01JZZa89AbbI07+KQqbHJNNdv4JU2aTWrXPer0jd4x8tFN48YH8WedfBpgPOxHV0aE ifcQ==
X-Gm-Message-State: AOAM530CnJEPXWSFuNg4AvYi82jxDfPHlt+x5EMj0oM2nGDWoRu1u/oV Ost3uT8tFhBo3X9ysvmgN3k=
X-Google-Smtp-Source: ABdhPJzDxBNqE0PslxBzTvkrYW8S78DLXwybhaZZzdv+cgZMQ7krDNfyhE1o2DThgIvsz0zHFKNRrw==
X-Received: by 2002:a19:6801:: with SMTP id d1mr20782002lfc.561.1617133962996; Tue, 30 Mar 2021 12:52:42 -0700 (PDT)
Received: from jonathartonsmbp.lan ( []) by with ESMTPSA id p25sm2793469ljn.61.2021. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Mar 2021 12:52:42 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\))
From: Jonathan Morton <>
In-Reply-To: <>
Date: Tue, 30 Mar 2021 22:52:41 +0300
Cc: Praveen Balasubramanian <>, "" <>, "" <>, "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
To: Vidhi Goel <>
X-Mailer: Apple Mail (2.3445.9.7)
Archived-At: <>
Subject: Re: [tcpm] [EXTERNAL] Re: 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: Tue, 30 Mar 2021 19:52:51 -0000

> On 30 Mar, 2021, at 10:18 pm, Vidhi Goel <> wrote:
>>>> How is the sender of the pure ACKs supposed to react upon receiving the feedback that ACKs themselves are causing congestion? Option B conveys this additional information but how is it supposed to be used? Can a pure receiver get into such a state and does it need to start throttling ACKs?
>>> This was discussed briefly during the WG. The receiver will act by reducing the ssthresh and cwnd (if it is not already minimum). This wouldn’t impact the receiver’s ACKing, but it would have an impact when the receiver starts sending data.
>> The information could also be used to tune the Delayed Ack ratio, via (for example) Gomez' Ack Rate Request option.  That *would* have a congestion control effect on ack traffic.
> I don’t think we should change the ACK ratio, at the very least, we shouldn’t reduce it. ACKs are used to convey crucial information to the sender esp. when there is a congestion.

That really depends which direction the congestion is in.  No doubt plenty of acks are helpful when the forward path is congested.

But we are talking here about congestion being reported, by the network, to be on the path carrying the ack stream.  This means that either the network is on the point of *dropping* acks (and would already have done so, if they weren't marked ECT), which effectively changes the ack ratio without the endpoints' consent - OR the ack stream is now the limiting factor, via the ack clock mechanism, for the forward-path data throughput, so reducing the number of acks being generated would allow an increase in goodput.  In both cases, a mechanism for the sender to adjust the ack ratio of the receiver makes sense.

We can defer detailed discussion of the advantages or otherwise to threads on Ack Rate Request.

 - Jonathan Morton