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

Jonathan Morton <> Wed, 23 March 2022 13:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2234F3A12B5 for <>; Wed, 23 Mar 2022 06:42:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.857
X-Spam-Status: No, score=-1.857 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, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_BLOCKED=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 uRhzOf0gAUj6 for <>; Wed, 23 Mar 2022 06:41:58 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E9FF93A12A0 for <>; Wed, 23 Mar 2022 06:41:57 -0700 (PDT)
Received: by with SMTP id h11so1886982ljb.2 for <>; Wed, 23 Mar 2022 06:41:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ulaDYA89t9SUThYccncK0vre1sQ36sjXYvsN8+EqQaY=; b=lfg2IqKC2i/VR0kjyOhNbYiNfhTYy1qw6W01AYbcvNTrb3qjmgW7BZphG8MqGJiDWu 844Tt2A7zpHAfV5tszHTmcXI4dt+GHWqTNM67EcsRC5P7UZp4XxaX1OeFP+hqgNbJaaw J4z5sutyd+RqJMph2w7OZo+PNle+wH3ma9bRrCAm6h1vsoHQoEj1veDrAGGPQNScLCN2 D7gOAVqCpQ8sxVV4rpnqxhwSGtJltenuu785cpU26GmsZrGugKzq2Lrey2hdSFSQFPUf qlWBweu94Fx9wxd8sTbZ73t5OwdfseCtCeMfHoihCH7PqRJcSNbNv28kT4DIRqWDTDff Y02Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ulaDYA89t9SUThYccncK0vre1sQ36sjXYvsN8+EqQaY=; b=WP4stpJiJeLhUG1p+CvGP1ZMYlodBVWPRZg+nxFEs5xcR4swllf7hREFSaK664x9WD +slw50jYgb5a9V3UnyvdEiXNFGaezYUyVj7R8mmJZSStSZpu5kpBDWiTpAxqatKMKc7d 69VpD9bgNvRUY9YadWSO6sOFYzV+lpoACf+FbUTwxs6JcdD7Ab3Yw1Gevj/YEwjChib0 f9NHLUuCQ+Qrg+qVYtfrynq5tDuZvWn8ahqOHd13rMHaVsOh3Bz5NIWOPjN1FvrYg3+m WPAq/4aVcglDg5k+RGVJBRQ2pJbVIdVl+RmWA2nhDC/ruJ6bWBN30jmJ1PYYb8VMuyPv MEtw==
X-Gm-Message-State: AOAM530LxYxnRj4T2zsA2lrEDU0dF6pMWJiJLSdU7Exa9XivVez4nlCA 8fWzijCJAlcJJo5E4vWedBYOLKcF//M=
X-Google-Smtp-Source: ABdhPJwZ07Ej9x3QH3CyDHafOLPRCSaal7NOtpEJctquijXPUmDK+s2joqYWisSqz4brMMMDelD0+Q==
X-Received: by 2002:a05:651c:1043:b0:247:ed00:c152 with SMTP id x3-20020a05651c104300b00247ed00c152mr54341ljm.448.1648042915647; Wed, 23 Mar 2022 06:41:55 -0700 (PDT)
Received: from ( []) by with ESMTPSA id g19-20020a2e3913000000b00247dea5b468sm518lja.115.2022. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 23 Mar 2022 06:41:55 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
From: Jonathan Morton <>
In-Reply-To: <>
Date: Wed, 23 Mar 2022 15:41:54 +0200
Cc: tcpm IETF list <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Gorry Fairhurst <>
X-Mailer: Apple Mail (2.3654.
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 13:42:03 -0000

> On 23 Mar, 2022, at 3:25 pm, Gorry Fairhurst <> wrote:
>>> 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.

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

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.

 - Jonathan Morton