Re: [quicwg/base-drafts] Add note about stale ACK frames breaking ECN (#2879)

Martin Thomson <> Tue, 09 July 2019 06:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AC1FC120307 for <>; Mon, 8 Jul 2019 23:24:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.001
X-Spam-Status: No, score=-8.001 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, RCVD_IN_MSPIKE_H2=-0.001, 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 R-vm7Zhzt3g7 for <>; Mon, 8 Jul 2019 23:24:37 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 36385120108 for <>; Mon, 8 Jul 2019 23:24:37 -0700 (PDT)
Date: Mon, 08 Jul 2019 23:24:35 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1562653475; bh=RZZmHQD7UlzsDf5/os3Pm+jO6bxtKwr/gUudnzXatyg=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=kkHTn1OhjjkvqzYNq1exBMl+VD/2m++59PQx9CsVuW4EFg9acO7+Kvvk4xbdJNrf1 caFHEgDWleK1mlwxHlg9Ebm64pIsXzUu612VndnSpxpE57qqQ/624V3WsdDOLKuq7W tkqoPysZAV+AG3X6lPpR77mLCdEX0TGXVzxPl6uY=
From: Martin Thomson <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/2879/review/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] Add note about stale ACK frames breaking ECN (#2879)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d243323db171_486e3f84d00cd96c1416281"; 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: Tue, 09 Jul 2019 06:24:42 -0000

martinthomson commented on this pull request.

> @@ -3154,11 +3154,13 @@ to be greater than the number of packets acknowledged in an ACK frame.  When
 this happens, and if verification succeeds, the local reference counts MUST be
 increased to match the counts in the ACK frame.
-Processing counts out of order can result in verification failure.  An endpoint
-SHOULD NOT perform this verification if the ACK frame is received in a packet
-with packet number lower than a previously received ACK frame.  Verifying based
-on ACK frames that arrive out of order can result in disabling ECN
+Processing counts out of order can result in verification failure.  This can
+happen when packets containing ACK frames are reordered in the network, or if a
+sender retransmits an ACK frame with stale information.  An endpoint SHOULD NOT
+perform this verification if the ACK frame is received in a packet with packet
+number lower than a previously received ACK frame or if the ACK frame does not
+acknowledge any new packets. ACK frames that arrive out of order can result in

I would prefer instead to say that you MUST NOT retransmit stale ACKs AND to require that new ACKs always increase the largest acknowledged (or the ACK range with the largest packet number cannot be discarded).  Then we only need to say that endpoints skip ECN validation when the largest acknowledged does not increase.

That's strictly less good than using packet number, because newly acknowledged packets don't always increase the largest acknowledged, so we could mention that checking for an increasing packet number is even better, but that only enables validation more often.

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