Subject: [quicwg/base-drafts] Revalidation for ECN (#4037)

From: Martin Thomson <[email-masked]>
Date: Wed, 19 Aug 2020 17:02:21 -0700

It&#39;s OK to try to validate ECN again if it fails.

This removes duplicate text and replaces it with a forward reference.

Closes #4028.
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/4037

-- Commit Summary --

  * Revalidation for ECN

-- File Changes --

    M draft-ietf-quic-transport.md (8)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/4037.patch
https://github.com/quicwg/base-drafts/pull/4037.diff

-- 
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/4037

---

From: ianswett <[email-masked]>
Date: Wed, 19 Aug 2020 18:25:57 -0700

@ianswett approved this pull request.

-- 
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/4037#pullrequestreview-471066595

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 20 Aug 2020 00:49:49 -0700

@gorryfair commented on this pull request.

> @@ -3892,6 +3889,7 @@ errors are detected.
 Endpoints validate ECN for packets sent on each network path independently.  An
 endpoint thus validates ECN on new connection establishment, when switching to a
 server's preferred address, and on active connection migration to a new path.
+If validation fails, an endpoint could also periodically attempt validation.

Why is this a could. Ignoring ECN is inappropriate and dangerous to the health of other flows. (If a flow received CE-marks it could reasonably assume ECN is working, if it see nothing it needs at some point to recheck this works.)

I'd expect this to be needed: Why therefore is this not a SHOULD?

> @@ -3843,11 +3843,8 @@ instead of dropping it.  Endpoints react to congestion by reducing their sending
 rate in response, as described in {{QUIC-RECOVERY}}.
 
 To use ECN, QUIC endpoints first determine whether a path supports ECN marking
-and the peer is able to access the ECN codepoint in the IP header.  A network
-path does not support ECN if ECN marked packets get dropped or ECN markings are
-rewritten on the path. An endpoint validates the use of ECN on the path, both
-during connection establishment and when migrating to a new path
-({{migration}}).
+and the peer is able to access the ECN codepoint in the IP header; see
+{{ecn-validation}}.

I think the new text is wrong. Support by the endpoint isn't sufficient. The path validation is required to use ECN, and this spec needs to say this for each new path.

-- 
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/4037#pullrequestreview-471345472

---

From: mirjak <[email-masked]>
Date: Thu, 20 Aug 2020 04:00:03 -0700

@mirjak commented on this pull request.

An endpoint receiving CE marks should always feed them back to the sender. Validation is about actively marking packets as ECT by the sender. However, I think it would be nice to be more explicit and add a reference to the respective section at least.

I'm also in favour or keep this text here. It's a bit of redundant but I think it's useful to make this clear from the beginning.

-- 
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/4037#discussion_r473883795

---

From: Martin Thomson <[email-masked]>
Date: Sun, 23 Aug 2020 19:02:07 -0700

@martinthomson commented on this pull request.

This is a could and not a SHOULD because making a recommendation would require us to make that recommendation actionable.  That means describing the circumstances under which revalidation is desirable.

I realize that not all routes are static, but you would have to establish a case for revalidation in order to make any sort of statement with normative force.

I don't see how this text contradicts.  Given that it is old, all I'm reading from this feedback is a preference to keep text that better belongs in the referenced section.  And that section already concentrates on the path aspects (dropping, corruption).

-- 
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/4037#discussion_r475304700

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 24 Aug 2020 02:18:09 -0700

To be clear: I suggest we keep the text that says: "An endpoint validates the use of ECN on the path, both during connection establishment and when migrating to a new path ({{migration}})." 

... Although the simplest way to do this is to monitor an increase in the ECN counters reported.
 
I suspect there have been too many threads/issues related to ECN text (some have diverged and some concluded with no action) and those people (me included)  involved should now read a clean version of the ECN text. I do not expect this text to be hard to finalise.

-- 
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/4037#discussion_r475453977

---

From: Martin Thomson <[email-masked]>
Date: Mon, 24 Aug 2020 04:03:37 -0700

This appears immediately above:

> It is possible for faulty network devices to corrupt or erroneously drop packets with ECN markings.  To provide robust connectivity in the presence of such devices, each endpoint independently validates ECN counts and disables ECN if errors are detected.

This would seem to suffice.

-- 
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/4037#discussion_r475521508