Bounds on safe use of "Ignore CE" for ECT(1)?

[gorryfair]

• To me, Ignore CE for arbitrary numbers of packets, does seem like it can be quite dangerous to the proper operation of ECN in the way understood for ECT(1), unless this is somehow constrained on the number of packets that are received. ECN is intended to be an early reaction to congestion and this delays a CC reaction, and if it is for a lot of packets I think that's likely an issue, although a few packets would likely be fine !!!! I think this needs CC safety guidance in the text, even if the guidance differs for ECT(0).

[goelvidhi]

I agree with this but probably the sender wouldn't use both Ignore-CE and L4S at the same time. Hopefully, folks will understand that from reading the draft. :-)

[gorryfair]

Hmmmm ... If this really only applies to sender setting ECT(0) let's say that - I can see it works in relation to ABE or RFC3168 reactions, and not L4S. Explaining this, the impact would then be clear when (?) ECT(0) usage is finally deprecated. Likely a PR can achieve this.

[janaiyengar]

We can say that "The Ignore-CE bit SHOULD NOT be set if ECT(1) is negotiated."

[ianswett]

Added to the existing PR about Ignore CE: #116

[mirjak]

Actually to me it's really not clear why the Ignore CE is useful at all as you always want at least the first CE (in a row or in a RTT) as fast as possible. E.g. for Accurate ECN this is explicitly specified in Section 3.2.2.5.1 (https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-accurate-ecn#section-3.2.2.5.1). I think that's where this discussion belong and not in this draft, given I don't see a reason for a sender side signal as I don't think this is actually congestion control dependent - all congestion control algorithm should react to CE marking and do so as quickly as possible.

[goelvidhi]

This was discussed in detail at #87

I do agree with @mirjak that I am not convinced with the use of this field and why should a sender be allowed to set this.