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

mirjak <notifications@github.com> Tue, 07 January 2020 10: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 B7F7C12001E for <quic-issues@ietfa.amsl.com>; Tue, 7 Jan 2020 02:35:35 -0800 (PST)
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 JHdhNA3k5BCt for <quic-issues@ietfa.amsl.com>; Tue, 7 Jan 2020 02:35:32 -0800 (PST)
Received: from out-4.smtp.github.com (out-4.smtp.github.com [192.30.252.195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FF6E120019 for <quic-issues@ietf.org>; Tue, 7 Jan 2020 02:35:32 -0800 (PST)
Date: Tue, 07 Jan 2020 02:35:31 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1578393331; bh=UcMt1TmrpPrgAh+FmyP0bFJnCflQ/NuQntEaSEmo+qg=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=peLvcLuZcZ6x7fmyaLW1GkN8cALOtCbYxyJ/2V2ntW1cSmQjGTLn/xmGGz+vkKAwY 0u2gh0DafHUdq+poJjxMKFgyeFyAIVON4m0OzdX+Y/FrQFTMD1FKNRxif2dxvE1Uon 1NexqNleYuxqi0YMQ1AaINtaPRY2Mh5zp73gZgG8=
From: mirjak <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK5UDYDQHMYDOSM6NQ54EGIXHEVBNHHCBC7C3M@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/3320/review/339150098@github.com>
In-Reply-To: <quicwg/base-drafts/pull/3320@github.com>
References: <quicwg/base-drafts/pull/3320@github.com>
Subject: Re: [quicwg/base-drafts] An example ECN validation algorithm (#3320)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e145ef34e620_2093fe879ccd96c90784e"; 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
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/TR9O_iSNwGRhd5gk3rtPHByI160>
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, 07 Jan 2020 10:35:36 -0000

mirjak 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.

Given that black-holing is rare, I'd rather keep simply all packet ECT-marked until a failure is detect. If black-holing is happening, that's actually the easiest case to detect (as you will have a time-out). Moreover if you plan to send more than one cwnd of packets with ECT marks in testing, you will get blocked anyway as you can't send anymore packets without receiving an ack. 

> @@ -3488,6 +3489,54 @@ Even if validation fails, an endpoint MAY revalidate ECN on the same path at any
 later time in the connection.
 
 
+#### Exemplary ECN Validation Algorithm {#ecn-alg}
+
+Each time that an endpoint commences sending on a new network path, it
+determines whether the path supports ECN.  If the path supports ECN, the goal is
+to use ECN.  Endpoints might also periodically reassess a path that was
+determined not support ECN.
+
+This section describes one method for testing new paths.  This algorithm is
+intended to show how a path might be tested for ECN support.  Endpoints can
+implement different methods.
+
+The path has an ECN state that is one of "testing", "unknown", "failed", or
+"capable".  In the "testing" and "capable" states the endpoint sends packets
+with an ECT(0) marking; otherwise, the endpoint sends unmarked packets.

I would say: "the endpoints sends packet with an ECT marking, by default ECT(0);"

> +To start testing a path, the ECN state is set to "testing" and existing ECN
+counts are remembered as a baseline.  It should not be necessary to disregard
+the effect of packets sent prior to starting testing, though it is necessary for
+a sender to remember what markings were used for every packet that is
+acknowledged; see {{ecn-ack}}.
+
+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."
+-->

Currently the ECN validation section says "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."
Why is that not sufficient?

> @@ -3488,6 +3489,54 @@ Even if validation fails, an endpoint MAY revalidate ECN on the same path at any
 later time in the connection.
 
 
+#### Exemplary ECN Validation Algorithm {#ecn-alg}

If we want an algorithm like this I think this should go into the appendix.

> @@ -3473,6 +3473,7 @@ to be greater than the number of packets acknowledged in an ACK frame.  When
 this happens, and if validation succeeds, the local reference counts MUST be
 increased to match the counts in the ACK frame.
 

Related note: I just realised that we don't test the case where ALL ECT get remarked to CE which should also lead to failure.

-- 
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/3320#pullrequestreview-339150098