More strongly recommend ECN marking

[martinthomson]

In #3320, @mirjak suggested that a different algorithm might be better to recommend enabling ECN and only disabling it if a failure is detected.

That algorithm adopts the same posture as the draft: that ECN is optional and that endpoints are permitted to be cautious in enabling it. If we want to adopt the view that ECN works and endpoints are required to use it unless it breaks, that's a bigger change.

I open this issue, while being aware that this is re-opening something we discussed and agreed previously, without there being new information to present. Chairs, if you do think we should discuss this, it's a design issue.

[ekr]

I would not be in favor of reopening this.

[mirjak]

Just to clarify the proposal was that if you decide to enable ECN, you should just do it and only disable if you notice a failure, instead of having the more complicated probing logic that we have right now (in the appendix I think)

[huitema]

The Interop Matrix shows that out of 14 implementations doing active tests, only 3 demonstrate ECN support. No ill will, but major places like AWS or the Windows OS do not support ECN, so it is not clear what more text in the spec would change.

[martinthomson]

This is just about this one paragraph:

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.

The concrete proposal would be to remove this paragraph.

[larseggert]

Discussed in ZRH. Proposed resolution is to close with no action.

[mirjak]

I will make a proposal for an editorial PR for the paragraph mention above to make it sounds less scary that this risk exists.