Re: [tcpm] Why draft-gomez-tcpm-ack-rate-request?

Jonathan Morton <> Fri, 25 March 2022 15:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 22A8F3A0EFC for <>; Fri, 25 Mar 2022 08:43:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.859
X-Spam-Status: No, score=-1.859 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 CSOmAcXMBHtH for <>; Fri, 25 Mar 2022 08:43:02 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 97EAA3A0EC4 for <>; Fri, 25 Mar 2022 08:43:02 -0700 (PDT)
Received: by with SMTP id e16so13997070lfc.13 for <>; Fri, 25 Mar 2022 08:43:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/5T1Pz46DMpqKTz5dC1OHALYc1LTDfpnGsHvJhDSJ4o=; b=OnUCPZ95egJ406vys+ftrUpiG59b4CoqbCin3T7pXoXHAVbOFZpuR6Z8CP31WiMtQ/ nj/AHspTcBY/BV4BdwRdh1o9wMkuqBkyMTJpjy2d/LHjMRq5KzPzfWJ+DwuS7YFCxd+8 +TMgTwVILclSG77R65uixe0Tm0w/DAbHA2Josc8yupvgYf8ak+YeSUlevjTxk/dLQYHB bkj6YybKGvZRZ1/AOVmKMuF6sW16EMKQWX4+N6hCa2ZjprmCmQpTwSCJruZu5PgIUsg5 +5rdX9zjuRxC9tljtsuPJZYz/HXMN1B/5dlECgfHligN1d79fvL3gMOrl8eAm7pG+gT9 8B7Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/5T1Pz46DMpqKTz5dC1OHALYc1LTDfpnGsHvJhDSJ4o=; b=YEK2oOSDBFK++9oIdUqcujlJ8toKGjEaH9AHSihAAoetQgPn24UUfnw1SZmxSudUjV 6UTUNF/EJDjxkgJGUubEr+Tp6sb5iTzy28QS3R39PYSV+jn0MiODUhE01Nri9qnjYTnC 5btDwX4y8G7oZWA789AddRakEsWplrPso57l6K9f//Obzrs071QAj+ozNw5iZY/3OQGZ gZJLRiI6MVncwIuqzKrN3b0A1+MimzFSIPQhWelGYwF8mueECQHSCPr1JD3W6b8tY8GE /+tr7LaQO5F9Ywauj8TsmR7YtHidqSZbjAh7NG88amD669YcgVTd5E5LPseqJYBP6fzf Xm4g==
X-Gm-Message-State: AOAM530CsrFcbKV1+bLV966gnFw/dtz4NJwph6DY2wa/tjnuURsiNrko L503+9k+1v6NGDe85BjyRBfVI8kASnA=
X-Google-Smtp-Source: ABdhPJzsLVb7B0ASE4J66AR+1izVDZbBYpVhgcJHpRxkXrCRDbyd/aQ6jhYu35V24QtU9xO5ROBs3w==
X-Received: by 2002:a05:6512:33d6:b0:44a:7966:d688 with SMTP id d22-20020a05651233d600b0044a7966d688mr1329805lfg.11.1648222980197; Fri, 25 Mar 2022 08:43:00 -0700 (PDT)
Received: from ( []) by with ESMTPSA id m21-20020a197115000000b0044895f0608asm742319lfc.37.2022. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 25 Mar 2022 08:42:59 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
From: Jonathan Morton <>
In-Reply-To: <>
Date: Fri, 25 Mar 2022 17:42:58 +0200
Cc: Gorry Fairhurst <>, tcpm IETF list <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <>
To: Bob Briscoe <>
X-Mailer: Apple Mail (2.3654.
Archived-At: <>
Subject: Re: [tcpm] Why draft-gomez-tcpm-ack-rate-request?
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, 25 Mar 2022 15:43:07 -0000

>>> I would also note that ARR offers an alternative signalling method (to AccECN) for effectuating Generalised ECN, as applied to pure acks in particular.  I think ARR is conceptually and mechanically simpler for implementers than AccECN is.
> [BB] If I read between the lines, I believe you are categorizing the combination of AccECN and generalized-ecn (ECN++) as just one very narrow application of them: ACK congestion control. Although the combination of AccECN and ECN++ makes ACK-CC possible, that wasn't one of the original motivations for either.*

You're reading something that I didn't write.  I don't need to comment on the goals or applicability of AccECN here, only those of ECN++ and TARR.

> Whatever, if we run with this narrow focus, TARR wouldn't be enough to deploy ACK CC. It solely gives the control signal, not the measurement in the other direction that would be needed to drive that control.

Ack CC would be triggered by the detection of ack-losses or ECN signals on the acks.  These acks travel in the opposite direction to data segments, ie. from the "receiver" to the "sender".  TARR allows the sender, which is in a position to observe these losses or ECN markings *and* knows what the data-oriented CC algorithm needs, to inform the receiver what density of acks it is desirable for the receiver to send.

In other words, TARR could be tried *today* - even without ECN++, and certainly without AccECN.  As a signalling mechanism, TARR is, in fact, sufficient on its own to implement Ack CC.

As you note, ECN++ intends to allow the use of ECT on TCP ack and control packets, not just data segments, as well as on retransmitted data segments which are presently sent Not-ECT.  ECT implies, to the network, that the endpoints will use explicit congestion signals (ie. CE marks) to reduce traffic volume on the flow and in the direction that the marks were applied in the network.  Presently, TCP only does that for data segments (as per RFC-3168).

TARR adds a mechanism for an appropriate congestion response for CE marks applied to TCP acks.  This is completely in keeping with ECN++ goals.  Hence, the successful negotiation of TARR could be taken as sufficient to permit setting ECT on pure acks, if not the other cases as well.  This assumes, of course, that an appropriate Ack CC response is either written into TARR, or is explicitly implied by its presence.

 - Jonathan Morton