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

Bob Briscoe <> Wed, 23 March 2022 16:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B2D113A18C3 for <>; Wed, 23 Mar 2022 09:51:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.11
X-Spam-Status: No, score=-2.11 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=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 Xx4R_PkwKjdc for <>; Wed, 23 Mar 2022 09:51:24 -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 061023A157F for <>; Wed, 23 Mar 2022 09:51:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:From:References:Cc:To:Subject:MIME-Version:Date:Message-ID:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=cACKWse+fCy30Gf2ODEB/fB+i95p+6rBXNQXNTCKvRg=; b=rohr+vVgW2hGr75BVuXjiNT+LJ NDGPw+o/5FvSwWO4PdVUJJoEa50vgzJ/jlkjxT1GuzwOwYd6V+cxKa6eOkDiPVLFG3xFSYk+MbZ1/ D0vk9MWlKdFAf7Jg/J5GLc00QTXvEeIh1fTQ4iyXX1ZoQHdo5GofsAuBLFVV1JKgg3af91mCtw/X1 R6gKC28QoJAhpCWGbV1eNd5yxU7/zFGKnE/jx8pWkwYQ7dRgv3+vljxLOGoh/po4wOfxAM3c6UqIo /C7WFnis5W7mgAETao+rz9o4D2A0rinjL6mv+8/1aekDRyr20tU3MZwYzZWoIEShyLLzZzgiSfACI ih4UrnTQ==;
Received: from ([]:54590 helo=[]) by with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from <>) id 1nX4Cm-0006Wb-1i; Wed, 23 Mar 2022 16:51:22 +0000
Message-ID: <>
Date: Wed, 23 Mar 2022 16:51:20 +0000
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0
Content-Language: en-GB
To: Gorry Fairhurst <>
Cc: tcpm IETF list <>, Jonathan Morton <>
References: <> <> <>
From: Bob Briscoe <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id:
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: Wed, 23 Mar 2022 16:51:30 -0000


On 23/03/2022 13:25, Gorry Fairhurst wrote:
> On 23/03/2022 14:06, Jonathan Morton wrote:
>>> On 23 Mar, 2022, at 2:00 pm, Gorry Fairhurst <> 
>>> wrote:
>>> Thanks again for raising questions about ACK traffiuc - I'm quite 
>>> passionate we look again at AcK traffic volume and rate.
>>> I've just reread and I'm still quite skeptical this is the right 
>>> solution - look forwrad to the talk.
>>> Why is this so important to use a TCP option to signal, rather than 
>>> just specify a better method?
>>> 1. An option increases the probability that someone might 
>>> block/change the option on path.
>> This sounds like a counterproductive argument to me.  I believe we 
>> should be trying to *reduce* the amount of ossification inherent to 
>> the interaction of IETF protocols with overzealous middleboxes.  If 
>> this option is blocked en route, the transport will fall back to the 
>> typical delayed-ack behaviour, so there should be little if any harm.
>>> 2. Any receiver that sees this option has anyway to decide how to 
>>> process ACKs - and mkight also need to deal with offload.
>>> - The use-case for IOT might not need an option:
>>> For receivers that see one segment/RTT then ACKing each segment 
>>> immediately seems reasonable. Sending 2 segments would make anyway 
>>> have this effect.
>>> When would you not wish to send fewer ACKs?
>> There are cases where the sender wants to receive more frequent acks 
>> in order to infer things about the network path, particularly for 
>> advanced congestion control algorithms.
> Which IETF CC needs this?

[BB] Chicken and egg:
* CC is unilaterally deployed at one end.
* Without a 2-ended protocol like TARR, no CC that needs a facility like 
TARR can be implemented.
If we use a chicken and egg criterion like your question, we'll never 
get chickens or eggs.

A Data Point:
     To use paced chirping at the sender, we had to manually disable 
del-ack at the receivers in order to work well during slow start (it 
works with del-ack, just not very well).
Paced chirping was a research project, rather than an IETF CC, precisely 
because there is nothing like TARR out there.
Chicken and egg.

>>   IoT senders would also benefit from the ability to operate 
>> efficiently with single-MSS congestion windows, which is most easily 
>> achieved by explicitly signalling this intent to the receiver.
> That's my point - any system using a window of 1 MSS is a special case 
> easily noted, that does not need negotiated.

[BB] The receiver doesn't know the RTT, so 'easily' is overstated. But 
your point has some validity.

More generally, receiver heuristics are not a panacea...

Another data point from paced-chirping:
     The receiver heuristic in Linux that disables delayed acks during 
slow start doesn't work with paced chirping, 'cos it is specific to the 
pattern of slow-start packets, which is precisely what we were trying to 
improve on with paced chirping (i.e. the Linux heuristic has ossified 
slow-start, which is why we need sthg like TARR to override it).


>> Without ARR, the only mechanism for this is the PSH flag, which is 
>> not defined with the required on-the-wire meaning, but instead 
>> indicates desired behaviour for the receiving socket API.
>>> 3. The use cases for asymmetry or processinbg load might not need an 
>>> option:
>>> I don't understand the motive here, in QUIC some have been using one 
>>> ACK every ~10 packets
>>> in some implementations (wuth whatever caveat to do something 
>>> differenet for the first ~100 packets).
>>> I'd like to argue this is enough "control" for most cases, and not 
>>> so much "ACK traffic" in many cases where that matters.
>> There's about a 25:1 ratio between the size of a data-segment packet 
>> and an ack packet in IPv4 - and it's closer for IPv6. This makes it 
>> relatively easy for modern traffic patterns to cause congestion on 
>> the smaller direction of an asymmetric-capacity link to limit 
>> practically available capacity in the other direction, with today's 
>> delayed-ack specifications which effectively require one ack for 
>> every two data segments.
>> Existing solutions to this problem are not at all elegant.  One 
>> relies on a side-effect of current NIC hardware releasing batches of 
>> received packets, all of which may be acked as a unit.  Another 
>> relies on some middlebox actively dropping acks when it decides that 
>> too many are passing through it - which is inefficient on several 
>> levels simultaneously.  ARR puts some control over this back in the 
>> hands of the transport endpoints, and may even result in a reduction 
>> of power consumption and shared-medium contention.
>>   - Jonathan Morton
> I'm not saying don't change the spec. - far from it. It's just I don't 
> see the case why this signalling is needed to change the way a 
> receiver works.
> Gorry
> _______________________________________________
> tcpm mailing list

Bob Briscoe