Re: [quicwg/base-drafts] Reword Immediate ACK Recommendation (#2424)

Martin Thomson <> Wed, 06 February 2019 00:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1CD60128CE4 for <>; Tue, 5 Feb 2019 16:49:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -12.553
X-Spam-Status: No, score=-12.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, 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_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 UsssZCmdtcUm for <>; Tue, 5 Feb 2019 16:49:51 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 555A3128B01 for <>; Tue, 5 Feb 2019 16:49:51 -0800 (PST)
Date: Tue, 05 Feb 2019 16:49:50 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1549414190; bh=BS2btT5NiFfUEcCgcOr0A3R/qfV5Ih72tOfJW7Pk2YA=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=XK2ecCFfisJNavXbHhB5iG0pheDwbvAIm09Pkt2luS4s2NTL8RKLXgiPTzgQmgFny 0jFdSBYjN4DX9z/V1c+YYD0GtG5D/EWWocok1YI319jeAnNNCgPOMI9mRpaeAfY/h2 dJBaUFp0CWX243jnkZ6pna6TxphEWJrXjGenjSAo=
From: Martin Thomson <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/2424/review/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] Reword Immediate ACK Recommendation (#2424)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c5a2f2e9ab22_15bd3fa0f84d45bc1153f1"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinthomson
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: Wed, 06 Feb 2019 00:49:53 -0000

martinthomson commented on this pull request.

I think that this is better, though I'd like to confirm design intent.

> @@ -134,6 +134,11 @@ Crypto Packets:
 : Packets containing CRYPTO data sent in Initial or Handshake
+Out-of-order Packets:
+: Packets that do not increase the largest received packet number for its
+cryptographic context by exactly one.

Do you want to add: "Packets can arrive out of order as a result of packets ahead of them being lost or delayed."  I think that's accurate.

> @@ -244,11 +249,9 @@ ack-eliciting packet. QUIC recovery algorithms do not assume the peer sends
 an ACK immediately when receiving a second ack-eliciting packet.
 In order to accelerate loss recovery and reduce timeouts, the receiver SHOULD
-send an immediate ACK when it receives a new packet which is not one greater
-than the largest received packet number. A receiver MAY send immediate ACKs
-for the next few ack-eliciting packets that are received, but SHOULD NOT
-send an immediate ACK for more than 1/8 RTT after receiving an out-of-order
+send immediate ACKs for an interval after it receives an out-of-order packet.
+This interval SHOULD NOT exceed 1/8 RTT unless more out-of-order packets arrive
+during the interval.

So the idea is that every out-of-order packet triggers a 1/8 RTT interval of immediate acknowledgments?

I thought that the idea was to disable the sending of immediate acknowledgments if out-of-order packets started becoming routine.  That is, if you have a highly unreliable path, then immediate acknowledgments aren't helping repair errors, they are just noise.

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