Re: [quicwg/base-drafts] ACK generation recommendation (#3304)

Ryan Hamilton <> Tue, 17 December 2019 15:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 749271209D0 for <>; Tue, 17 Dec 2019 07:28:21 -0800 (PST)
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 FN7yfL2jL9ey for <>; Tue, 17 Dec 2019 07:28:19 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 43A6D12012C for <>; Tue, 17 Dec 2019 07:28:19 -0800 (PST)
Date: Tue, 17 Dec 2019 07:28:18 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1576596498; bh=ilRZBfK+bn/QmlFCqy10sz8stam0WI4L4cGB5wyXMPE=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=PxDZzgsMGdf5fcZ3kCrhTslESQC5Fr6gJG7ND1YGA7zt9DBJ18pnvzwy56c8e6Qi6 lZ+pY0qpZlUsOGPlRWnbZadU7wA/TXTp5+VDPnt8QL5ikJMhOa4Aga6CNX0bQ2uRrD GMdpQSNuDq3seyyrxbB3JcFJh/MVSv5+4atJuCh0=
From: Ryan Hamilton <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/3304/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] ACK generation recommendation (#3304)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5df8f412575f2_14873fda69ecd9601113d2"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: RyanAtGoogle
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, 17 Dec 2019 15:28:22 -0000

On Tue, Dec 17, 2019 at 6:48 AM Nick Banks <> wrote:

> Gorry raised the point that in experiments, this generates way too many
> ACK packets in high bandwidth networks, such as satellite networks. This
> has noticeable CPU costs for QUIC, for both sending as well as for
> receiving.
> Could you expand on this? I find this to be an extremely general
> statement, and not very helpful in understanding the real motivation for
> any possible changes. You say it "has noticeable CPU costs for QUIC", but
> are you referring to the client, server or some middle boxes somehow?
It can happen to either endpoint. Consider an HTTP/3 download. The client
ends up burning a bunch of CPU *sending* ACK, and the server a bunch of CPU
*processing* ACKs.

> Assuming you're worried about the CPU costs on the server side, has anyone
> explicitly measured the differences in CPU cost for generating different
> number of ACKs per RTT? What's the effect on FC? Fewer ACKs will mean the
> sender (I'm assuming the server?) is going to have to buffer more, and FC
> windows might be hit more often. Is this really such a big problem that is
> requires a spec change? In V1?
We've definitely noticed the CPU costs at Google on high
bandwidth connections with long flow. This led us to implement a variety of
ACK reduction strategies which reduced CPU use significantly. I think a
QUIC sender which sends ACKs of every 2 packets without and further limits
will be unable to take full advantage of the network and yes, we should
explicitly permit this in V1.

I don't believe we measured the impact on flow control. Our clients
typically advertise a very large flow control window which basically does
not get hit.



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