Re: [quicwg/base-drafts] ECN verification text (#2752)

mirjak <> Thu, 08 August 2019 15:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3B4AC120134 for <>; Thu, 8 Aug 2019 08:58:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0GuxVSUtQfoI for <>; Thu, 8 Aug 2019 08:58:48 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 39920120164 for <>; Thu, 8 Aug 2019 08:58:48 -0700 (PDT)
Date: Thu, 08 Aug 2019 08:58:46 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1565279927; bh=9uPh27ZOoW9Fx8U7RjBb7jH2dW9Yze65gw3R7yBmC6E=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=Y5GvoCqtTAMelEGCYTzPJO6/EYU1FD9gy7+mJt7ls4rAubYgNy8LCfFGnGRc3z99x HnYPZyl/umkRQxrepi5NR1g5J7BSGatguSpH46Yoak6pVVFYy4M3LkBO/d/5l6urBy Ccrh2wphj/XjC8EPTb55vSNir/RkaBrEnilTqMn4=
From: mirjak <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/2752/review/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] ECN verification text (#2752)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d4c46b6ec49a_2c083fb7ab8cd96068225d"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: mirjak
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: Thu, 08 Aug 2019 15:59:03 -0000

mirjak commented on this pull request.

> -reduced throughput or other undesirable side-effects.  To reduce this risk, an
-endpoint uses the following steps to verify the counts it receives in an ACK
+To start ECN validation, an endpoint SHOULD do the following when sending
+packets on a new path to a peer:
+* Set the ECT(0) codepoint in the IP header of early outgoing packets sent on a
+  new path to the peer {{!RFC8311}}.
+* If all packets that were sent with the ECT(0) codepoint are eventually deemed
+  lost {{QUIC-RECOVERY}}, validation is deemed to have failed.
+To reduce the chances of misinterpreting congestive loss as packets dropped by a
+faulty network element, an endpoint could set the ECT(0) codepoint in the first
+ten outgoing packets on a path, or for a period of three RTTs, whichever occurs
+first.  Implementations MAY experiment with and use other strategies.  An

RFC8311 says: "Protocols and senders MUST NOT use the ECT(1)
      codepoint to indicate ECT unless otherwise specified by an
      Experimental RFC in the IETF document stream."
So I don't think we should talk about use of ECT(1) without a pointer to RFC8311.

However, for this sentence I still don't see why normative language is needed.

And If think if we want to say something about ECT(1) we should rather say something like: "ECT(1) is reserved for experiments by RFC8311. If such an experiment is implemented, the described validation methods might apply as well to ETC(1)." However, that actually doesn't say much...

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