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

[mirjak <[e-mail]>]

mirjak commented on this pull request.



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

Maybe say: "When the expected risk of ECN-based blackholing is low, an endpoint can also
	simply send all packets marked with ECT(0) until validation fails."
I would also like to point people to some measurement data, e.g.: "Recent studies have detected potential ECN-related connectivity problems in less than 0.3% [ECNmeasure]"

[ECNmeasure] Brian Trammell, Mirja Kühlewind, Piet De Vaere, Iain R. Learmonth, and Gorry Fairhurst. 2017. Tracking transport-layer evolution with PATHspider. In Proceedings of the Applied Networking Research Workshop (ANRW '17). ACM, New York, NY, USA, 20-26. DOI: https://doi.org/10.1145/3106328.3106336

> +
+* 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

RFC8311 does not define use of ECT(1) as interchangeable with ECT(1) anymore and therefore advises endpoints to only use ETC(0) which classic ECN. I think it's right to only talk about ECT(0) here, or if you want to mention that ECT(1) should also use for experimentation with new ECN based signal approaches, you have to point to RFC8311.

-- 
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#pullrequestreview-272462951