Re: [quicwg/base-drafts] MUST ACK each ack-eliciting packet once (#3092)

MikkelFJ <> Tue, 22 October 2019 13:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 210C0120831 for <>; Tue, 22 Oct 2019 06:24:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.999
X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qwtKfRvWfhQg for <>; Tue, 22 Oct 2019 06:24:10 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5001B120830 for <>; Tue, 22 Oct 2019 06:24:10 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 57F5A52091E for <>; Tue, 22 Oct 2019 06:24:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1571750649; bh=whkYNzVDSd4jKcTQHxiNw/jKD7KFFDSbwDLSqrryxLQ=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=xGjmyr0DfqHCAUaIVcKR8TeQR+iYdmvffM9L0RHDViCwYhB1fGxAU3tl9399OEK+D 6rWXVY9h1tHJ1vVY3FPYWu97QZ0VdpLy64UmTsV3ED4QgRtYq0J/DMMUJiKQfCHYss WOV8i0qkTh2WTZ+df8Fia5XbCfiV758F39R5vai4=
Date: Tue, 22 Oct 2019 06:24:09 -0700
From: MikkelFJ <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/3092/review/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] MUST ACK each ack-eliciting packet once (#3092)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5daf02f9489c8_6fe73f89458cd9681937e2"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: mikkelfj
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
Archived-At: <>
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 22 Oct 2019 13:24:12 -0000

mikkelfj commented on this pull request.

> @@ -3007,9 +3007,6 @@ guidance offered below seeks to strike this balance.
 ### Sending ACK Frames {#sending-acknowledgements}
-An ACK frame SHOULD be generated for at least every second ack-eliciting packet.
-This recommendation is in keeping with standard practice for TCP {{?RFC5681}}.
 An endpoint MUST NOT excessively delay acknowledgements of ack-eliciting

I don't want to make this a hard argument, I'm just slightly concerned. Maybe it is a non-issue, or maybe potential issues are shadowed by other concerns such as PTO. Some devices might not want to fire up a transmitter radio more often than necessary. But generally I'm just concerned with a MUST that cannot be enforced or fully controlled - you can easily claim it works under usual conditions but it might not under abnormal conditions. A SHOULD would make it possible to drop packets under those a conditions. A MUST would either have to make assumptions that are hard to prove correct, or have complex code to handle edge case where ACK's queue op, or violate the MUST. I suspect most implementations would go for the latter and hope they don't violate by sending ACK's often enough.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: