IETF Logo Mail Archive

Re: Two Notable Ack Frequency Issues

Martin Thomson <mt@lowentropy.net> Tue, 14 September 2021 03:41 UTC

Return-Path: <mt@lowentropy.net>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CD5B3A08FB for <quic@ietfa.amsl.com>; Mon, 13 Sep 2021 20:41:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=ZlS3xqPy; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=MJwVGoke
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 TP86-QepNTLj for <quic@ietfa.amsl.com>; Mon, 13 Sep 2021 20:41:23 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B40C3A08F8 for <quic@ietf.org>; Mon, 13 Sep 2021 20:41:22 -0700 (PDT)
Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 316AC5C00A3 for <quic@ietf.org>; Mon, 13 Sep 2021 23:41:22 -0400 (EDT)
Received: from imap41 ([10.202.2.91]) by compute5.internal (MEProxy); Mon, 13 Sep 2021 23:41:22 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm3; bh=9UoLYuVy/bT/L1oXUmAQf9jOsMMwRKZ GBDkJUNcKKzo=; b=ZlS3xqPy31IcHMwNn9khwoSdToTmAeMnx1iNTeBKrXJhJpu ODTCtPv8mDrI2s973a2NcqnT13IZ0r6QstbMjCTc18QfnARseRwJ5v5FBJLZJ3Yy LJAEBmPjnbpbtQ1hcoJZaJPtEctNbXyRFKbuZrc9ozfLZIY5F9wnGOI0FdW+rKA2 6EMWQ/tr58tFPbNMibehm/pWkRDPHZU/QRqrTdMYORHvkX5S139nqfZEIgNxw4w6 X1iqGhPj6dICxmNAwZaCXGXxNDWv+cdDKv8XOy8Cldokir/FKLY7QY8htG8WvX8m eLLWl9hhEjFYPn4V9Q8Z4PIhIESieTTvbgbaELA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=9UoLYu Vy/bT/L1oXUmAQf9jOsMMwRKZGBDkJUNcKKzo=; b=MJwVGokeuaqEmWIxCn0UuK B+2FxxVKxlEea6YVb55lBmXlvHRHKn1PWUuxmdJIb9EFN0lRa98QUele9ykBQVsn xGZpNMRBpOYSLwTvWR/sucOrtsyff/k4u7gxXPMglZvShMXlMYhFcXI9o7QicWXR DQPRxjmM6jYbm3ZvAYGvbLE7T/7MmnFKpS4zvWUebWUVTni012EAPyCXc+9flYtF TNPXwTxSu1dcFuJsQ3eQI8RSYXyEYwjktTNWn8HKw3ps83qjQR/l/qYzPuLu55m2 TFS6XkREnc94WgkHMqAu1kz98FYGbYwv4WTSd+27jLKi0t9dpqQZ0XfEigNq0GHA ==
X-ME-Sender: <xms:4RlAYbCYMSpVEyRZ-trW9pOyvLPGh2sSWBrlw7sUMzu-KKsXpBQW-A> <xme:4RlAYRg_gjDQOkUfoCQu7w8IPh1bQee7VlQBIGfBapL3vvvkssmmcCZivRL3mQfbT sNB5FKmnMWIxB-gmEo>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrudegkedgjeduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpeekteeuieektdekleefke evhfekffevvdevgfekgfeluefgvdejjeegffeigedtjeenucevlhhushhtvghrufhiiigv pedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvg ht
X-ME-Proxy: <xmx:4RlAYWnFpJ3CSuVab1d27UrogKLneUmtv0gwkNZ-b0kHu9fllLp73Q> <xmx:4RlAYdzPM3jt8JXuoy0iPxUCdq8p3qffsSOOzKWtielsJGBgKIIo9Q> <xmx:4RlAYQTt4l22S88rxVwqvstvIO9c9Qc-NiBvwoxa4ffUmYBQKsDN5Q> <xmx:4hlAYXdp-itcE3rEuK5-V5op5wiIE8M7XTdImN0v3xE9g7KZIAr9Wg>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id E32FE3C0821; Mon, 13 Sep 2021 23:41:21 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.5.0-alpha0-1291-gc66fc0a3a2-fm-20210913.001-gc66fc0a3
Mime-Version: 1.0
Message-Id: <012f35ca-1e54-4ba1-800f-76a6d053039a@www.fastmail.com>
In-Reply-To: <CAKcm_gM0nbBB8y+jjSh7ZwnL9zvkkZUeYMinkQetmwNjRSORuA@mail.gmail.com>
References: <CAKcm_gPe_0E3Yje=qT07hC2uSt+srWT7EwbhiYNsPq8Q+pFFiw@mail.gmail.com> <d17cbbc0-a35c-45ba-afee-11e92b08b373@www.fastmail.com> <CADdTf+hWM6UCQZkSbKxN3KARLxGmASxBnEg8VAjb6=xSFNyWLA@mail.gmail.com> <2eff1b46-65cb-4822-a498-11357ac4cd23@www.fastmail.com> <5021E5FE-F19E-44BA-BA50-F9807CF30FCB@fb.com> <CAKcm_gM0nbBB8y+jjSh7ZwnL9zvkkZUeYMinkQetmwNjRSORuA@mail.gmail.com>
Date: Tue, 14 Sep 2021 13:41:02 +1000
From: Martin Thomson <mt@lowentropy.net>
To: quic@ietf.org
Subject: Re: Two Notable Ack Frequency Issues
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/L5s8SFWgpByW5OWdQhlg0JO9dxA>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Sep 2021 03:41:29 -0000

On Tue, Sep 14, 2021, at 12:04, Ian Swett wrote:
> I've substantially changed my PR on NO_ACK to be DELAY_ACK.

I'm not sure that I understand this change.  The PR reads:

> The DELAY_ACK Frame causes the receiver to send an immediate acknowledgement,

Is that missing a negation somewhere?

If I'm guessing correctly, what you want to say is that this packet should start the delayed acknowledgment timer if it is not already started, but not be cause for an immediate acknowledgment.  That is, no immediate acknowledgment is generated even if this packet causes the number of unacknowledged packets to hit the Ack-Eliciting Threshold or it appears out of order and Ignore Order is not enabled.

This effectively disables both the Ack-Eliciting Threshold and a setting of Ignore Order = 0.  Only the timer remains.  That might be safer than completely disabling acknowledgment, but I think my previous position stands on this.

> On IMMEDIATE_ACK, it both solves a clear problem

I can see how IMMEDIATE_ACK works (I had forgotten previous discussions and the linked discussion is a little thin).  I'm OK with defining a frame for this purpose.

FWIW, this is better than packet number skipping (which was always a kludge).

v2.23.0 | Report a Bug | By Email