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

Jana Iyengar <notifications@github.com> Tue, 09 July 2019 06:01 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9685D12013D for <quic-issues@ietfa.amsl.com>; Mon, 8 Jul 2019 23:01:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CEnnF2m_T0fz for <quic-issues@ietfa.amsl.com>; Mon, 8 Jul 2019 23:01:10 -0700 (PDT)
Received: from out-10.smtp.github.com (out-10.smtp.github.com [192.30.254.193]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 699C7120122 for <quic-issues@ietf.org>; Mon, 8 Jul 2019 23:01:10 -0700 (PDT)
Date: Mon, 08 Jul 2019 23:01:09 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1562652069; bh=rc37IjSbar81yVxFWSmnS6HpGQvqiaZq1jqkPo4KDJY=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=tnt0+OFj5+YwYuXNI3IS7F4BHfC7Exz6iAC+bLb0Bnk2NAQtdRpyj9lAU8AAwokOG jTOIRCKCQO0muyrtcwKd0JIKO+5v8+C5+TqSTDxH8F7A/ukVSfzG5k80ASTSdWFXT+ rmUctRzHxYPquMOkfDSf8dm2k3TE04XWhx8E51yw=
From: Jana Iyengar <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKZP46S4E2H6FGDLPGV3GFQCLEVBNHHBXP7DOI@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/2879/review/259282704@github.com>
In-Reply-To: <quicwg/base-drafts/pull/2879@github.com>
References: <quicwg/base-drafts/pull/2879@github.com>
Subject: Re: [quicwg/base-drafts] Add note about stale ACK frames breaking ECN (#2879)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d242da5564d3_4c2f3fd3608cd96c1079674"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: janaiyengar
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/sqCItk-OY1Iwy7aRt4Af0-1BGx8>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Jul 2019 06:01:13 -0000

janaiyengar 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
-unnecessarily.
+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'm not sure that we need to collapse this. I think it's reasonable to say that the largest acked should increase, though it's going to be too broad. Any scenario that has reordering of received packets will have ACKs being sent where the largest acked is not increasing.

If the packet number of the received ACK is increasing, it should be adequate, with this one exception (which ought to be rare) where the sender retransmits stale ACKs. I'd rather cover the common case of looking at packet number to determine whether the count is valid, and handling this exceptional case additionally.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2879#discussion_r301407837