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

[Martin Thomson <[e-mail]>]

@martinthomson 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.

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.

> @@ -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 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