Re: [quicwg/base-drafts] An example ECN validation algorithm (#3320)

Martin Thomson <> Tue, 07 January 2020 02:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 108A9120041 for <>; Mon, 6 Jan 2020 18:13:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.999
X-Spam-Status: No, score=-7.999 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_IMAGE_ONLY_32=0.001, 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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nz3gJRoeuuZQ for <>; Mon, 6 Jan 2020 18:13:55 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1A74312002E for <>; Mon, 6 Jan 2020 18:13:55 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 9FEB7261663 for <>; Mon, 6 Jan 2020 18:13:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1578363234; bh=Wg6PEa/VM5x3hOvUpAxqNHULPoIr0IKTpJcO6hBUaxI=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=FmKmNeWdzDMh8YPKJgSfJvAaqPzk6mDAKGqN5WOffjurkxNRK95lZNDiGqwswwKk+ gwcvJTvPf9g3/um/zHuHetiNFzkQojMeGb6XhaiK7lQiGwxcrP9mKQC8V1F3GXbrVf I4VIc21xDL/iIvpdjxG6e8KMtNyuotJORNCCncqI=
Date: Mon, 06 Jan 2020 18:13:54 -0800
From: Martin Thomson <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/3320/review/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] An example ECN validation algorithm (#3320)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e13e962591b6_4d793fcf688cd96812319a"; 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, 07 Jan 2020 02:13:57 -0000

martinthomson commented on this pull request.

> +
+The testing period runs for a number of packets or round trip times as
+determined by the endpoint.  During this time, packets sent are marked with
+ECT(0).  The goal is to limit the duration of the testing period, but to ensure
+that enough marked packets are sent that it is likely that ECN counts will
+provide a clear indication of how the path treats marked packets.
+<!-- Do we need a more concrete recommendation here?  For instance, I might say
+"Endpoints could test with packets that amount to between 1 to 2 times the
+initial congestion window over a period between 1 to 2 times the estimated RTT."
+After the testing period ends, the ECN state for the path becomes "unknown".
+From the "unknown" state, successful validation of the ECN counts an ACK frame
+(see {{ecn-ack}}) causes the ECN state for the path to become "capable", unless
+no marked packet has been acknowledged.

This extra condition caught me by surprise.  The problem is that if every packet you mark is lost, the ECN counts remain valid, but you have a fair indication that the path is a black hole.  That's not worth belabouring because black holes are exceedingly rare, but the extra condition seems necessary even if we don't provide a whole lot of explanation.

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