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

Jonathan Morton <chromatix99@gmail.com> Wed, 23 March 2022 13:42 UTC

Return-Path: <chromatix99@gmail.com>
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 2234F3A12B5 for <tcpm@ietfa.amsl.com>; Wed, 23 Mar 2022 06:42:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.857
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 uRhzOf0gAUj6 for <tcpm@ietfa.amsl.com>; Wed, 23 Mar 2022 06:41:58 -0700 (PDT)
Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9FF93A12A0 for <tcpm@ietf.org>; Wed, 23 Mar 2022 06:41:57 -0700 (PDT)
Received: by mail-lj1-x230.google.com with SMTP id h11so1886982ljb.2 for <tcpm@ietf.org>; Wed, 23 Mar 2022 06:41:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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 smtpclient.apple (178-55-202-24.bb.dnainternet.fi. [178.55.202.24]) by smtp.gmail.com with ESMTPSA id g19-20020a2e3913000000b00247dea5b468sm518lja.115.2022.03.23.06.41.54 (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.100.0.2.22\))
From: Jonathan Morton <chromatix99@gmail.com>
In-Reply-To: <7f55afcf-059c-4a6f-9733-2034bbcef760@erg.abdn.ac.uk>
Date: Wed, 23 Mar 2022 15:41:54 +0200
Cc: tcpm IETF list <tcpm@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <0B05AB01-0C37-4558-8525-2951245C6277@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>
To: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
X-Mailer: Apple Mail (2.3654.100.0.2.22)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/SvGnBJkrKeT_KVay8krSDjWs5_8>
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:42:03 -0000

> On 23 Mar, 2022, at 3:25 pm, Gorry Fairhurst <gorry@erg.abdn.ac.uk> 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