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

Gorry Fairhurst <gorry@erg.abdn.ac.uk> Wed, 23 March 2022 13:28 UTC

Return-Path: <gorry@erg.abdn.ac.uk>
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 1DDFD3A11E3 for <tcpm@ietfa.amsl.com>; Wed, 23 Mar 2022 06:28:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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
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 FGF34rr5oy-g for <tcpm@ietfa.amsl.com>; Wed, 23 Mar 2022 06:27:55 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id A82113A1275 for <tcpm@ietf.org>; Wed, 23 Mar 2022 06:27:25 -0700 (PDT)
Received: from [31.133.155.40] (dhcp-9b28.meeting.ietf.org [31.133.155.40]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 048131B0014F; Wed, 23 Mar 2022 13:27:16 +0000 (GMT)
Message-ID: <7f55afcf-059c-4a6f-9733-2034bbcef760@erg.abdn.ac.uk>
Date: Wed, 23 Mar 2022 14:25:56 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:91.0) Gecko/20100101 Thunderbird/91.7.0
To: Jonathan Morton <chromatix99@gmail.com>
Cc: tcpm IETF list <tcpm@ietf.org>
References: <3546045c-454c-611f-be50-a6de6bd6b03b@erg.abdn.ac.uk> <8956E182-4F45-414D-85D9-14A654A2398D@gmail.com>
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
In-Reply-To: <8956E182-4F45-414D-85D9-14A654A2398D@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/LjmdM2lvap6Ljs10K5whlwTBaKk>
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 13:28:00 -0000

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?
>   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.
> 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