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

Jana Iyengar <notifications@github.com> Thu, 08 August 2019 20:20 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 43F281200C5 for <quic-issues@ietfa.amsl.com>; Thu, 8 Aug 2019 13:20:35 -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 xJAmUxOEgdwd for <quic-issues@ietfa.amsl.com>; Thu, 8 Aug 2019 13:20:32 -0700 (PDT)
Received: from out-20.smtp.github.com (out-20.smtp.github.com [192.30.252.203]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CB9212002F for <quic-issues@ietf.org>; Thu, 8 Aug 2019 13:20:32 -0700 (PDT)
Date: Thu, 08 Aug 2019 13:20:31 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1565295631; bh=ir/HdANGx5i3F39bLU8jk17Bbi9LhTh3j5vluL2p6p0=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=xrDh4Z1prcKho5aqKxZ8n7snajL89mUTImqMCL+d9EAhs1sPnp1j5/mgLN9/CMm22 3B5+5qU9WRRAZ88cPvY7FzFWTFQKD3SjYauWG4Lp/pTNovf8pEk1DMcem2SIcNAeol th/6xWi8tELUOLiepMAqLaUqc6G6N4WKYoTIgccc=
From: Jana Iyengar <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK4DAOYQDCVS6GFEQLF3LG3I7EVBNHHBVKABIA@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/2752/review/272803504@github.com>
In-Reply-To: <quicwg/base-drafts/pull/2752@github.com>
References: <quicwg/base-drafts/pull/2752@github.com>
Subject: Re: [quicwg/base-drafts] ECN verification text (#2752)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d4c840fdb177_687b3facae4cd96c102320"; 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/4ow7EqNMvYCpmayAsRwPJA6E4V8>
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, 08 Aug 2019 20:20:35 -0000

janaiyengar 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
-frame.
+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

Thanks for the text, @martinthomson. I've tried to wrestle the text to resolve these concerns, take a look. @mirjak, the normative exists here because there's a SHOULD above on a specific sending pattern (see line 3133).

> +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
+endpoint could send the first ten packets interleaved: five packets marked with
+ECT(0) or ECT(1) interleaved with five unmarked packets.  An endpoint could also
+simply send all packets marked with ECT(0) or ECT(1) until validation fails.

I'm not sure that we need to say anything here about the prevalence of ECN blackholing. No matter what the prevalence, this spec will have to specify methods that work when ECN blackholing is a problem. It seems to me that this text probably belongs in the applicability draft.

> -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
-frame.
+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

I think we only need to specify one method that can be used as a default, and suggest that implementations can use others too. I'm going with the suggestion of removing other methods entirely from this text because I don't think we need to discuss considerations of using other methods. If I'm in the minority, then I would suggest that we still keep it out of this PR, and add more methods in a separate PR.

> +
+* 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.  Alternate strategies are possible.  For example, an endpoint could send
+the first ten packets interleaved: five ECT(0)-marked packets interleaved with
+five unmarked packets.  This allows the endpoint to more clearly identify
+congestive loss as such.  Implementations MAY experiment with and use other
+strategies.
+
+#### Receiving ACK Frames
+
+An endpoint that sets ECT(0) or ECT(1) codepoints on packets it transmits MUST

I've cited 8311 for the text on sending ECT(1). This text is about what to do when receiving ECT(0) or ECT(1), and so I'm not citing 8311 here.

Unless you're suggesting that we scrub out all mentions of ECT(1) in the text here. I'm not sure that's necessary though, since the rules of validation do not change even when a future spec allows the use of ECT(1).

>  
 * Any increase in either ECT(0) or ECT(1) counts, plus any increase in the CE
   count, MUST be no smaller than the number of packets sent with the
   corresponding ECT codepoint that are newly acknowledged in this ACK frame.
   This step detects any erroneous network remarking from ECT(0) to ECT(1) (or
   vice versa).
 
+Processing ECN counts out of order can result in validation failure.  An
+endpoint SHOULD NOT perform this validation if this ACK frame does not advance
+the largest packet number acknowledged in this connection.

Good point. I tried to think of ways in which the path-level largest acked goes down while the connection-level largest acked goes up, but failed. I think connection-level might be a slightly stronger constraint than we want, but I _think_ it's actually correct. 

> -setting ECT codepoints in subsequent packets.  Doing so allows the connection to
-be resilient to network elements that corrupt ECN codepoints in the IP header or
-drop packets with ECT or CE codepoints in the IP header.
+#### Validation Outcomes
+
+If validation fails, then the endpoint stops sending ECN markings in subsequent
+IP packets with the expectation that either the network path or the peer does
+not support ECN.
+
+Upon successful validation, an endpoint can continue to set ECT codepoints in
+subsequent packets with the expectation that the path is ECN-capable.  Network
+routing and path elements can change mid-connection however; an endpoint MUST
+disable ECN if validation fails at any point in the connection.
+
+Even if validation fails, an endpoint MAY re-validate ECN on the same path to
+the peer at any later time in the connection.

Turns out I don't need the hyphenation.

-- 
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/2752#discussion_r312216338