Re: [quicwg/base-drafts] Update ACK generation policy (#3501)

Gorry Fairhurst <> Sun, 22 March 2020 19:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 06ABB3A080C for <>; Sun, 22 Mar 2020 12:25:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.482
X-Spam-Status: No, score=-1.482 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_24=1.618, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, 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 KYhAE_zAjvsd for <>; Sun, 22 Mar 2020 12:25:45 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AAA9F3A080A for <>; Sun, 22 Mar 2020 12:25:45 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 92FEA9604C5 for <>; Sun, 22 Mar 2020 12:25:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1584905143; bh=KYHxvDS7dIKe5xgHSrVGHJ5K5Z+m5I63uoF8+cRs1ss=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=w6MuhGKqcfTv8XwbSbiYVGCndTkSnNWuxxOMne2dkTWR6YS23P6nCbgMRbZbdkFzU sHtWxgR/TdVHW6U1hMbnozrDNbq/V52FkRJEBwLIuxA182ocs9X+neEe323GBJIIdv zzaifGQ4v8CEAQ5PSjkyFitA/X5MhzgObFlKlLnM=
Date: Sun, 22 Mar 2020 12:25:43 -0700
From: Gorry Fairhurst <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/3501/review/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] Update ACK generation policy (#3501)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e77bbb784700_547f3fd285acd964772e4"; 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 Mar 2020 19:25:48 -0000

gorryfair commented on this pull request.

> @@ -3170,11 +3170,21 @@ delayed retransmissions from the peer. For Initial and Handshake packets,
 a max_ack_delay of 0 is used. The sender uses the receiver's `max_ack_delay`
 value in determining timeouts for timer-based retransmission, as detailed in
 Section 5.2.1 of {{QUIC-RECOVERY}}.
+The max_ack_delay needs to be set so that at least several samples can

Does that matter for there first RTT?  The sender still receives an ACK after IW packets (assuming IW packets are sent)? If it matters, let's figure out how to solve that.

If the RTT turns out to be smaller than max_ack_delay*n (n updates/sec), then you can reduce max_ack_delay. I think this replicates  the ACK policy in Chromium? - but would be happy to see a different formulation that generates sufficient ACKs.

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