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

"Scheffenegger, Richard" <> Fri, 29 July 2022 17:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D0604C14F74D for <>; Fri, 29 Jul 2022 10:32:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Status: No, score=-1.909 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_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=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 (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Y6TAsz67Uzy6 for <>; Fri, 29 Jul 2022 10:32:16 -0700 (PDT)
Received: from ( []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id F0896C14F738 for <>; Fri, 29 Jul 2022 10:32:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=badeba3b8450; t=1659115933; bh=xKWu8fvzJGDPbZzVESXIWzPkWhSbaybD5OBhqUubJlU=; h=X-UI-Sender-Class:Date:Subject:To:References:From:In-Reply-To; b=O8aGulXrlPDWSuXlINqZHOGk5cIN9yjKFCwh1WCxrzMMjKGRNT217htn4OYktoiH3 lKSnuW4rJIlk+nBa/64PyDX3W9ew3SC88fTYIZSIH5WWv7cyBGSuyXCLoGAqJlA+SN ycR9mK0Wa1OJDeH9l/cMD7ypRH+DFP9i/dlxcgZg=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [] ([]) by (mrgmx104 []) with ESMTPSA (Nemesis) id 1M26vB-1oJwgO1Caf-002UNn for <>; Fri, 29 Jul 2022 19:32:13 +0200
Message-ID: <>
Date: Fri, 29 Jul 2022 19:32:12 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0
References: <> <> <> <> <> <> <>
From: "Scheffenegger, Richard" <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:DoEginwsl/nt/PnjdcDdddiJv1keof0KhcEOZ9AWsuxj35HD9kk YRBRz614QX3WTAirUVFHFW99WN0wCZhJH7CU60sVzUKXt+Ll2ym5JWKxGziuGxcJh5EbMBn TMGBMDf+ljmnb/aDaoJ8E5lW2cP5fvaGf9APSe9DBolTcY/lw/rQTSAvuXNvOSI1JaokR+M dCg4z190A3iIvbPjymslA==
X-UI-Out-Filterresults: notjunk:1;V03:K0:vaKo7VsYTfA=:eStgUIqCrqXfkip7Rij7Va l24xXWt61SSuGp5c1ghdqYfG3aIRAIfrZmzGicR5gXzADfX4vmzfRoUxI7/hY0ey/Xzw4dOpJ ECdXdDfvjv24BIPKMrmxLUeDkkLMcruMincQ3V4LgRjWePR7RSiOXXip1IJnj6JyaGKbm3yJp YVIcpLlqnSRzJ7mV6X2YnozWm1f9ydPdToFNM3viqIhiVGWT2TxNYwJ+0tsRULSEZKdQtIxJm +sj1aUY5TYB1uMkjUnKNGDjT/p9pHJo1TS2HTOCZtMSCaPwDINnbghBeZ2O5GqsNL4hsjGeWl fxSdzrjWj4/2Bj8Gv4QF3xqYeZoL1COCjIsVoAWjNXW1TwAvAanlLTC1h37zz/QHgRQn9+6+J w/EDxazVVnI+FafkZ0UC1jw8nkpipUxaZ/J6OVP1PtqJBrAEILua1R/jVa68mF98BJsvpu7Gv 3PQS1j3EM+AIoaICQ/RB9g2qOe0oU/a/bVFY8gTV8JQSSrRVHD8uWFzXEE4L59CEhfUMhjnz0 hv9SS+pVnW5if5eIg94Xoxdrj+esem/QhROTmRCh8QyAwycDMDIKj3g651HSVDSkmZlT2WebX qwYSoEf1EzJqNhfGMtKmzlh4cbniGT9Oh4RdYy1spX7wBjCv4ZiwP2INIkiya2LHomWd5yt3q s6vyHEsMmxPzm2wfTgcmSu/a8of9k+9/mYvmB6kgp8smougsMXDEEtqc/v9ph9vi8x0071pjM X53LAVr2PsU946VJajAgf1DO+RSMtJvrbj07GP675N4nvMa1t7ncv5rx7+iUuqPIqPEIGLzjO 6SyHZ3vPsmupnkFVNjs6yDFlhzQjoebhkYaD0ZYuyWZDZKkplVpubGzv57ful+ltOyobgI1MR TzSah3nN4agC8/bEbIiz3IAu5b6EomFSZXaI3zZfrNfnzRpTurFKUITChXooJ/pOZAnFCKvx/ TeVSL47f6+7oAD+tIHsMvhyHtnBxtuMNIKkRQLdx2H+K0zz3QqDNZG6poZ911GcwrrlhSzWtj u1ZpIdHk/3Nyp55bmWLh/6xIIxb3SslzVktcFpA8uUE9mx9dH6Qt1LJYG0dtEx9cf39pPbJxC eM4j4HK5DnPVDBUdZNvTgqVkv/+kXZSB62v28Ybc/xzNfmzXlFhbHOrDA==
Archived-At: <>
Subject: Re: [tcpm] Why draft-gomez-tcpm-ack-rate-request?
X-Mailman-Version: 2.1.39
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, 29 Jul 2022 17:32:20 -0000

I want to point out, that RFC5690 is NOT a finalized document which
would be ready for implementation.

Among other aspects, no TCP option has been assigned at the time, and
some things would be done differently today (no separate SYN option ID,
maybe as an advisory not even require a SYN option at all...)

So if this is the direction this functionality takes, to revive the
RFC5690 work, those details still need to be fleshed out. Thus the
discussions were not in vain, and ultimately a document replacing
RFC5690 is still needed.


Am 29.07.2022 um 17:59 schrieb Bob Briscoe:
> Jonathan, Carles, [This email was prepared in Mar'22, but apparently I
> never clicked send - mea culpa, mea maxima culpa]
> On 25/03/2022 15:42, Jonathan Morton wrote:
>>>>> 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.
> [BB] Put simply, yes, negotiating TARR during the handshake could allow
> ECT to be used on pure ACKs, then the combination of ECT and TARR could
> be used for ACK congestion control, as well as the other uses of TARR
> (immediate ACK'ing, reducing unnecessary ACK processing).
> This is the same as ACK-CC [RFC5690], which allows ECT to be used on
> ACKs as part of ACK congestion control. In fact, TARR as a protocol is
> rapidly becoming nearly identical to RFC5690. Even though it was
> originally motivated by other use-cases. Indeed, I suspect we are close
> to reaching the point where we suggest that RFC5690 would suffice for
> the use-cases that ack-pull and TARR were for (except it contains some
> constraints on the ACK ratio that might need to be updated).
> I'm sorry to Carles if he's been given the run-around. I and others
> suggested he generalized his original ACK pull request to an ACK rate
> request, and none of us noticed that there was already RFC5690 at the
> end of that path.
> [BTW, the problem with your original posting was that you were trying to
> side-swipe at AccECN and ECN++ to the extent that you omitted to say
> what you *were* talking about: ACK congestion control. So we all had to
> "read something you didn't write," to work this out. The result was just
> confused readers, and a failed side-swipe.
> You didn't need to mention AccECN or ECN++ at all. Because "effectuating
> Generalised ECN, as applied to pure acks in particular" was just a
> circuitous way of saying "enabling ECN on pure ACKs." And when you were
> looking for "an alternative signalling method (to AccECN) for
> effectuating...", you just meant a way to negotiate an ACK-CC scheme.  ]
>>> 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.
> [BB] You say you need "The detection of ack-losses or ECN signals". This
> is precisely the "measurement in the other direction" that I say you
> haven't got with TARR alone. Taking each in turn...
> 1) ACK-losses. The data sender could only detect ACK losses if:
>      a)  it can be sure that the data receiver never stretches ACKs
> wider than the requested ACK ratio. In the -03 draft (at my suggestion
> actually) the data receiver only "SHOULD" abide by the ack rate request,
> so if it stretched the ACKs because it had insufficient resources (e.g.
> under attack) the data sender would confuse this to be ACK loss and tell
> it to slow the ACK rate. Although the protocol fails for a while during
> this process, at least it self-heals.
>      b) it can be sure that middleboxes (WiFi, CAKE, DOCSIS, satellite
> links, etc) are not thinning ACKs. Unfortunately, if there's ACK
> thinning, the data sender falsely detects ACK-loss, and tells the data
> receiver to slow the ACK rate. That might cause some ACK filters to thin
> fewer ACKs, and eventually self-heal. But that's often not going to be
> true - the degree to which many ACK filters remove ACKs changes all the
> time. For instance many WiFI boxes coalesce ACKs until they get a
> transmit opportunity. At the other extreme, ACK decimation might remove
> a fairly fixed proportion of the ACKs. This would not self-heal.
>          I don't think many/all of these ACK filtering behaviours were
> around when the ACK-loss-detection techniques were written in RFC5690.
> 2) ECN
> A data sender cannot detect ECN signals on ACKs unless they are set to
> ECT. It would be possible for a future draft of the TARR spec to allow
> ECT on ACKs once TARR has been negotiated in the handshake. That was why
> I said that TARR would need "the measurement in the other direction".
> TARR *today* doesn't do this.
>> In other words, TARR could be tried *today* - even without ECN++, and
>> certainly without AccECN.
> [BB] Yes. AFAIK, no-one has ever mentioned ECN++ or AccECN in relation
> to TARR.
>> As a signalling mechanism, TARR is, in fact, sufficient on its own to
>> implement Ack CC.
> [BB] Yes. No-one was saying otherwise (except, as I said, the TARR draft
> would need to add the measurement channel, by allowing ECT on ACKs once
> TARR is negotiated).
> Or, given you are only interested in ACK-CC, just use RFC5690, which
> already does and says all this.
>> 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).
> [BB] Yes.
>> 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.
> [BB] Yes. And it assumes that the TARR draft will add that endpoints
> supporting TARR can set ECT on pure ACKs. Or just use RFC5690.
> Bob
>>   - Jonathan Morton