Revalidation for ECN #4037
Revalidation for ECN #4037
Conversation
It's OK to try to validate ECN again if it fails. This removes duplicate text and replaces it with a forward reference. Closes #4028.
martinthomson
added
editorial
| @@ -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. | |||
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
| 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}}. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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).
|
Plan is to merge #4059 instead. |
It's OK to try to validate ECN again if it fails.
This removes duplicate text and replaces it with a forward reference.
Closes #4028.