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

Gorry Fairhurst <gorry@erg.abdn.ac.uk> Wed, 23 March 2022 12:00 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 []) by ietfa.amsl.com (Postfix) with ESMTP id 39E0C3A0C83 for <tcpm@ietfa.amsl.com>; Wed, 23 Mar 2022 05:00:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.909
X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 13lgGPg1WZTW for <tcpm@ietfa.amsl.com>; Wed, 23 Mar 2022 05:00:39 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk []) by ietfa.amsl.com (Postfix) with ESMTP id 8595B3A0C88 for <tcpm@ietf.org>; Wed, 23 Mar 2022 05:00:38 -0700 (PDT)
Received: from [] (dhcp-813d.meeting.ietf.org []) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id BCF941B0014F for <tcpm@ietf.org>; Wed, 23 Mar 2022 12:00:34 +0000 (GMT)
Content-Type: multipart/alternative; boundary="------------mUTRlohVSud4UBPR8bnBJ0ny"
Message-ID: <3546045c-454c-611f-be50-a6de6bd6b03b@erg.abdn.ac.uk>
Date: Wed, 23 Mar 2022 13:00:26 +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
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
To: tcpm IETF list <tcpm@ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/Ja-fI5mlJoW6BFS7q-SwDFvug9A>
Subject: [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 12:00:44 -0000

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

I'll look forward to seeing the slides and udnerstanding more,