Re: [quicwg/base-drafts] Fix to ECN section regarding validation (#2113)

Martin Thomson <notifications@github.com> Thu, 13 December 2018 06:35 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 167FC130DC4 for <quic-issues@ietfa.amsl.com>; Wed, 12 Dec 2018 22:35:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.46
X-Spam-Level:
X-Spam-Status: No, score=-9.46 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, 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: 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 4R1VOrreyOAf for <quic-issues@ietfa.amsl.com>; Wed, 12 Dec 2018 22:35:25 -0800 (PST)
Received: from out-6.smtp.github.com (out-6.smtp.github.com [192.30.252.197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17C4812875B for <quic-issues@ietf.org>; Wed, 12 Dec 2018 22:35:25 -0800 (PST)
Date: Wed, 12 Dec 2018 22:35:24 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1544682924; bh=9/fxrs0joXBSIIgcq5CWpkF3LekEJSFfjWlWP8BrUtI=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=Z5dhDSE7fsQtjJ4blrwRgopZECsOyfmjCThsawVb2ENM5tO+1bLc87UQbLTN471CV yXbxQxm449zmcScEM1YzRLYz6qqeKGfjNqL09VjKlY1j3vjRKvd5SNd61KtQQKA07J gG9nC3PFOqLE5+CchPtidWjmYqd8TllnXelIlpOM=
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab225e6d6663d97ed2a00f454b47977f3e905fd08292cf000000011829bfac92a169ce173be661@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/2113/review/184517682@github.com>
In-Reply-To: <quicwg/base-drafts/pull/2113@github.com>
References: <quicwg/base-drafts/pull/2113@github.com>
Subject: Re: [quicwg/base-drafts] Fix to ECN section regarding validation (#2113)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c11fdacfa3a_68d3f808ced45bc382885"; 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
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/3iIuh840qg7vMAd3zbsojiDvMdY>
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: Thu, 13 Dec 2018 06:35:27 -0000

martinthomson commented on this pull request.



> @@ -3018,11 +3018,23 @@ elements on the network path, an endpoint verifies the following when an ACK
 frame is received:

I think that we need a little restructuring here.

> To reduce the risk of bad ECN markings affecting the operation of an endpoint, an endpoint verifies the counts it receives when it receives new acknowledgements:
> 
> * \[bullets]
>
> This validation is only performed if the ACK frame increases the largest received packet number.  Reordered acknowledgments could have lower counter values and might not be successfully validated as a result.
>
> These counts might be inflated if acknowledgments are never received for packets that were successfully delivered.  If validation succeeds, an endpoint MUST increase its expected counter values to those it receives.

Note that I almost didn't use MUST on that last clause, because there is no interop loss from doing that; it only means that validation is less likely to catch bad markings.

I also removed the "If the sender does not have state to determine if a packet is newly acknowledged..."  Such a packet - such as a packet that is declared lost - will never be considered to be newly acknowledged.

Would you like this as a PR?

-- 
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/2113#pullrequestreview-184517682