Re: [quicwg/base-drafts] Add more context and text around ACK frequency (#3706)

Jana Iyengar <> Mon, 01 June 2020 02:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 525AE3A0AEA for <>; Sun, 31 May 2020 19:35:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.697
X-Spam-Status: No, score=-1.697 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, DKIM_VALID_EF=-0.1, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H2=-0.001, 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 otb_NGaUpJPc for <>; Sun, 31 May 2020 19:35:08 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id ED2893A0AE8 for <>; Sun, 31 May 2020 19:35:07 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3BAD6E0133 for <>; Sun, 31 May 2020 19:35:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1590978907; bh=fWWIAmXocOgwSedhjZWkNlUyBxLyaJnLz4TRRdeHC0Y=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=GWXqtMF4dHFdY6uNzhFqVjslbMfy5RCB0NVOvr1en58Chwz4F0U9ymub6jufHO8+x KTkjnenM9i8vVrVvOCoaB0m1HKQPSZpvUXKwVFijemFfvom4AWom8OPURByPzt7XzQ ldJUT+/BkHqPxeMKfB8NkhyAfKM0gOBe1p6wESmM=
Date: Sun, 31 May 2020 19:35:07 -0700
From: Jana Iyengar <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/3706/review/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] Add more context and text around ACK frequency (#3706)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5ed4695b2ba87_5bb73fbd0c2cd9644199252"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: janaiyengar
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: Mon, 01 Jun 2020 02:35:09 -0000

@janaiyengar commented on this pull request.

> -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.  An
-endpoint MUST NOT send a non-ack-eliciting packet in response to a
-non-ack-eliciting packet, 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.
+### Acknowledgement Frequency
+A receiver determines how frequently to send acknowledgements in response to
+ack-eliciting packets. This determination involves a tradeoff.
+Endpoints rely on timely acknowledgment to detect loss; see Section 5 of
+{{QUIC-RECOVERY}}. Window-based congestion controllers, such as the one in
+Section 6 of {{QUIC-RECOVERY}}, rely on acknowledgments to manage their sending

It's still quite accurate, IMO. Ultimately, increasing the congestion window increases the sending rate. That is the higher order point here -- that reducing ack frequency reduces the throughput of the sender.

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