Re: [quicwg/base-drafts] Move Generating Acknowledgements to Transport (#2916)

ianswett <> Wed, 11 September 2019 20:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 327AA1207FF for <>; Wed, 11 Sep 2019 13:20:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.898
X-Spam-Status: No, score=-7.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1NBEsEMZid35 for <>; Wed, 11 Sep 2019 13:20:12 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1FB89120289 for <>; Wed, 11 Sep 2019 13:20:12 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2ABB31C07C1 for <>; Wed, 11 Sep 2019 13:20:11 -0700 (PDT)
Date: Wed, 11 Sep 2019 13:20:11 -0700
From: ianswett <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/2916/review/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] Move Generating Acknowledgements to Transport (#2916)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d7956fb1bc68_299a3faf83ecd96c4598b"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: ianswett
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: Wed, 11 Sep 2019 20:20:14 -0000

ianswett commented on this pull request.

-Packets containing only ACK frames are not congestion controlled, so there are
-limits on how frequently they can be sent.  An endpoint MUST NOT send more than
-one ACK-frame-only packet in response to receiving an ACK-eliciting packet
-(one containing frames other than ACK and/or PADDING).  An endpoint MUST NOT
-send a packet containing only an ACK frame in response to a non-ACK-eliciting
-packet (one containing only ACK and/or PADDING frames), even if there are
-packet gaps which precede the received packet. Limiting ACK frames avoids an
-infinite feedback loop of acknowledgements, which could prevent the connection
-from ever becoming idle. However, the endpoint acknowledges non-ACK-eliciting
-packets when it sends an ACK frame.
+A receiver's delayed acknowledgment timer SHOULD NOT exceed the current RTT
+estimate or the value it indicates in the `max_ack_delay` transport parameter.
+This ensures an acknowledgment is sent at least once per RTT when packets
+needing acknowledgement are received.  The sender can use the receiver's
+`max_ack_delay` value in determining timeouts for timer-based retransmission.

Yes, probably.  This text is pre-existing, and maybe with max_ack_delay the 1 ack per RTT recommendation should be removed, but that's not an editorial change.

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