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

Martin Thomson <> Tue, 22 October 2019 04:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F3033120074 for <>; Mon, 21 Oct 2019 21:27:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.596
X-Spam-Status: No, score=-1.596 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_28=1.404, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_NONE=-0.0001, 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 JKs00wiba2dT for <>; Mon, 21 Oct 2019 21:27:13 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A6F4E12004F for <>; Mon, 21 Oct 2019 21:27:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed;; h=from:reply-to:to:cc:in-reply-to:references:subject:mime-version:content-type:content-transfer-encoding:list-id:list-archive:list-post:list-unsubscribe; s=s20150108; bh=eKjL7oauf5TlZEON4Fo0mNV4Dg4=; b=PQxPCTcpGkULXWAc 3NZMzJ3kV95gmOYxj20W9smJIeVmMXjoW0UV41sQ4KbUmh410m1zlw3Tq+lc2Kct pWMkyV3lNFKqo2scVkBnFgdHpF95ZRjB9IDxspxP94gnguxma/X771hV4xQmy11o WcD9DzTD+JUqxf6/2WdUkWSfIoE=
Received: by with SMTP id filter0762p1las1-26953-5DAE7585-15 2019-10-22 03:20:37.720729107 +0000 UTC m=+362320.577364192
Received: from ( []) by (SG) with ESMTP id Etm1cvoyT1KDZvtnWCZQDw for <>; Tue, 22 Oct 2019 03:20:37.666 +0000 (UTC)
Date: Tue, 22 Oct 2019 03:20:38 +0000
From: Martin Thomson <>
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_5dae757fb8425_61453fc220ecd96c1952e"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinthomson
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-SG-EID: l64QuQ2uJCcEyUykJbxN122A6QRmEpucztpreh3Pak2bNdNcDYe2NfJuMiGeyYjsGQM/3QIUCQWL1j SLbF8invjKqouRWWbOuPS6Da83Xut6Ns641pU9bSXQ4DPa1kDKLPtpYDOy3s3Ou9V9HZAg5UmJdPa6 HR3NQOciPTsDoyIqQlohKva1Z2u/Tr1a3p6lXSjiWqFcdjP30XaNdSIRzipTBbm/BCXX3tM8XjKjvm g=
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 04:27:15 -0000

martinthomson 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 think that we're still missing the "An endpoint MUST send at least one acknowledgment for every packet it receives and successfully processes."  This paragraph is mostly about max ack delay, which is fine, but it only really says that you can't excessively delay.

Sure, you could say that "never send" == "excessive delay", but you could also say that you can't delay something that never existed in the first place.

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