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

Bob Briscoe <in@bobbriscoe.net> Wed, 23 March 2022 16:51 UTC

Return-Path: <in@bobbriscoe.net>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2D113A18C3 for <tcpm@ietfa.amsl.com>; Wed, 23 Mar 2022 09:51:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.11
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xx4R_PkwKjdc for <tcpm@ietfa.amsl.com>; Wed, 23 Mar 2022 09:51:24 -0700 (PDT)
Received: from mail-ssdrsserver2.hostinginterface.eu (mail-ssdrsserver2.hostinginterface.eu [185.185.85.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 061023A157F for <tcpm@ietf.org>; Wed, 23 Mar 2022 09:51:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; 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 67.153.238.178.in-addr.arpa ([178.238.153.67]:54590 helo=[192.168.1.4]) by ssdrsserver2.hostinginterface.eu with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from <in@bobbriscoe.net>) id 1nX4Cm-0006Wb-1i; Wed, 23 Mar 2022 16:51:22 +0000
Message-ID: <c5307d33-7a39-4fe2-2877-2f3daaf1f024@bobbriscoe.net>
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 <gorry@erg.abdn.ac.uk>
Cc: tcpm IETF list <tcpm@ietf.org>, Jonathan Morton <chromatix99@gmail.com>
References: <3546045c-454c-611f-be50-a6de6bd6b03b@erg.abdn.ac.uk> <8956E182-4F45-414D-85D9-14A654A2398D@gmail.com> <7f55afcf-059c-4a6f-9733-2034bbcef760@erg.abdn.ac.uk>
From: Bob Briscoe <in@bobbriscoe.net>
In-Reply-To: <7f55afcf-059c-4a6f-9733-2034bbcef760@erg.abdn.ac.uk>
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 - ssdrsserver2.hostinginterface.eu
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: ssdrsserver2.hostinginterface.eu: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: ssdrsserver2.hostinginterface.eu: in@bobbriscoe.net
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/WiNRPVckjfOBVLOAlnBwBEB6OWM>
Subject: Re: [tcpm] Why draft-gomez-tcpm-ack-rate-request?
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Mar 2022 16:51:30 -0000

Gorry,

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 <gorry@erg.abdn.ac.uk> 
>>> 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).


Bob

>> 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
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/