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

[mirjak <[e-mail]>]

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