Re: [quicwg/base-drafts] CONNECTION_CLOSE is non-ack-eliciting (#3098)

Martin Thomson <> Tue, 22 October 2019 00:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CB5C6120A84 for <>; Mon, 21 Oct 2019 17:28:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Status: No, score=-8 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_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 uvu3MJ4jFh1Z for <>; Mon, 21 Oct 2019 17:28:27 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 07A8A120A7D for <>; Mon, 21 Oct 2019 17:28:27 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7F92C8C050E for <>; Mon, 21 Oct 2019 17:28:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1571704105; bh=PSRMXFoNmhCZ/89kUFWNZG0g3SWAPIkVDMCJQOm803M=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=TZg5R/qYMeDcOBUFgYR8ysqgZIeTJWozxCvrFaGCFiaIPBIbL9sq+QJf+hG+9ZSbd NcCtQ11K07izxQiVawRbVNmhJwyHBLXY9rwRd4ygD/wugJ0qZwmGWeiwhVKKMtWErm 9mQ8M6V9/F7vrXwzBEldOB+lRgHkRU7VSoAGl87s=
Date: Mon, 21 Oct 2019 17:28:25 -0700
From: Martin Thomson <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/3098/review/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] CONNECTION_CLOSE is non-ack-eliciting (#3098)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5dae4d296fcb6_54e63fef7e8cd96488379"; 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
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 00:28:29 -0000

martinthomson approved this pull request.

Seems right to me.  Editorial tweaks suggested.

> @@ -123,7 +123,8 @@ In-flight:
 Ack-eliciting Frames:
-: All frames besides ACK or PADDING are considered ack-eliciting.
+: All frames besides ACK, PADDING, or CONNECTION_CLOSE are considered

: All frames other than ACK, PADDING, and CONNECTION_CLOSE are considered

> @@ -2992,9 +2993,8 @@ valid frames? -->
 ## Generating Acknowledgements {#generating-acks}
 Endpoints acknowledge all packets they receive and process. However, only
-ack-eliciting packets (see {{QUIC-RECOVERY}}) trigger the sending of an ACK
-frame.  Packets that are not ack-eliciting are only acknowledged when an ACK
-frame is sent for other reasons.
+ack-eliciting packets trigger the sending of an ACK frame.  Packets that are not

Can we fix this here?  I know that this isn't this PR, but I would prefer to say:

ack-eliciting packets cause an ACK frame to be sent within the maximum ack delay.  Packets that are not

Or something like that.

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