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

ianswett <> Thu, 19 December 2019 15:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 74EBB120251 for <>; Thu, 19 Dec 2019 07:29:57 -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 gGC8dIDjIkRa for <>; Thu, 19 Dec 2019 07:29:55 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7021B1201B7 for <>; Thu, 19 Dec 2019 07:29:55 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 89575521D95 for <>; Thu, 19 Dec 2019 07:29:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1576769394; bh=FXhNGC9dSjtdBsryBpwWGOjDq3qJq8NPYFC+wAqBAD0=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=OOnvVarkX8RZmyzWkhdG/GQLEH7QPOYVUXMetkNkfmF3RFk8ZIooQEYM3qhh5oQ6F M3/hE0b1ARKb2ZEyWJoTpg/EGBi6c/ixUIdS04x8yq2CWMm1Oi3nndCA4FHv8IlHMT xzEpoQl4LtK3Rm4pMM1E8tFWlcNiTLIizrWZ40uM=
Date: Thu, 19 Dec 2019 07:29:54 -0800
From: ianswett <>
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_5dfb97727a090_38363fa1b58cd96c329192"; 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: Thu, 19 Dec 2019 15:29:57 -0000

@kazuho I was hoping to have the Chrome default be ACK every two packets and then use a frame or TP to change the behavior everywhere we're running BBR.  But I haven't done that yet.

@janaiyengar Your points are very strong.  We have a loads of evidence from QUIC and TCP that acking every 2 packets is not the right choice in many circumstances, so saying SHOULD seems quite odd.  On the other hand, I feel like we punted this issue when it was raised before(#1978 ), and I feel like this is a bit late to make large changes.

@junhochoi I would prefer to avoid sending a congestion controller, since that limits innovation going forward(ie: what if someone uses a new CC?).

Here are some possible options(feel free to suggest others):
1) We make the existing text a default, but not really a recommendation: ie: You should ACK every two packets, unless you know better.
2) We add a 'fraction of RTT' ack aggregation transport param that a peer can specify, which kicks in at 'some point' when the receiver thinks the sender is out of slow start or the receiver sending too many ACKs per RTT.  Also limit the number of packets in a single ACK to IW, in order to limit bursts to IW.
3) We add a frame for "Number of packets before sending an ACK", as discussed in #1978 
4) We say something about not ACKing more frequently than the timer granularity, unless IW has arrived.
5) We say you have to ACK every IW and within max_ack_delay, and that's it.  If you want an immediate ACK, skip a packet number.  This has costs in terms of ack frame size and datastructure size, and means we have to be more conservative about how many times to send an immediate ACK after receiving a gap(ie: probably only once).

There are(at least) three resources being conserved here: Sender CPU, Receiver CPU, and path bandwidth(or transmission opportunities, packet counts, etc), so no one has perfect information.

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