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

Gorry Fairhurst <> Sun, 22 December 2019 09:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DB8251200B2 for <>; Sun, 22 Dec 2019 01:50:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.596
X-Spam-Status: No, score=-6.596 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_IMAGE_ONLY_28=1.404, 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 rWuA1Xp7BpZx for <>; Sun, 22 Dec 2019 01:50:33 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 13A4712008C for <>; Sun, 22 Dec 2019 01:50:33 -0800 (PST)
Date: Sun, 22 Dec 2019 01:50:32 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1577008232; bh=Fw9kU37hZf5l9Y1XJmDKq8ipzCAmcRJKom5wzsWVV74=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=YCj1zq0c903wNShgEUs0mQqL6O8cmYt5I8ks3O1Ke0BdkrCNAjxTLs0cHBc2jnZcB MGuNIFMMt6whey9GHZCaZvQsZcw70uPHVfk+CNPOrQk6G6K82cY2Uhh95CdIatwkr0 uU8bJ1HWizvKWK6OtVCD5kaXilg+i35ixr/UzKVY=
From: Gorry Fairhurst <>
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_5dff3c6812add_5b203fef828cd96052291e"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: gorryfair
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: Sun, 22 Dec 2019 09:50:35 -0000

I like ACK every 10 (after the initial 100 received packets) as the basic recommendation. This is consistent with the idea that a sender can release packets in 10's (IW) ... and for rates of 10's -100's Mbps this provides a significant benefit in the case we looked at in terms of not being limited by paths that have asymmetry (it also helps with CPU usage) - which is where we arrived at in our PANRG talk. For example, without this the satellite broadband systems we work perform significantly worse than currently. Many networks have deployed ways to do this for TCP, and it's important we don't make experience with QUIC much worse than it needs to be on the paths that care about this.

At higher rates, you may well benefit from doing more - especially to reduce endpoint processing -  but I think that such larger changes (e.g., to 1/4 RTT) do interact with the CC and that level of change requires a lot more thought - because it interacts with other mechanisms.

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