Re: [tcpm] draft-ietf-tcpm-accurate-ecn-20: Testing for Zeroing of the ACE Field

[Mirja Kuehlewind <[e-mail]>]

Hi Neal,

I agree with you that we could probably revise the text slightly. I believe we didn’t really consider the case where we still get valid information in the option but not in the ACE field. So we also assume in section 3.2.3.2.5.  (Consistency between AccECN Feedback Fields) that the ACE field can be used as a consistency check for the option. However, for the case that your described below where you basically know that the ACE field is managed locally but the option seem to work, it would be sad to disable ECN completely.

Maybe we can/should relax the text a bit by restating it this way:

OLD
If the value of this ACE field is zero (0b000), for the remainder of the half-connection the Data Sender ought to send non-ECN-capable packets and it is advised not to respond to any feedback of CE markings.

NEW
If the value of this ACE field is zero (0b000), for the remainder of the half-connection the Data Sender is advised not to respond to any CE feedback in the ACE field and ought to send non-ECN-capable packets if no other CE feedback is reliably provided in the AccECN option.

Of course that leaves the question open when the feedback in the option is reliable, but maybe we can just leave this to the implementation and further experimentation.

Mirja



From: tcpm <[e-mail]> on behalf of Neal Cardwell <ncardwell=[e-mail]>
Date: Friday, 5. August 2022 at 03:23
To: "[e-mail]" <[e-mail]>, tcpm <[e-mail]>, Bob Briscoe <[e-mail]>, "[e-mail]" <[e-mail]>, "Scheffenegger, Richard" <[e-mail]>
Subject: [tcpm] draft-ietf-tcpm-accurate-ecn-20: Testing for Zeroing of the ACE Field

Re:
  https://www.ietf.org/archive/id/draft-ietf-tcpm-accurate-ecn-20.html

3.2.2.4. Testing for Zeroing of the ACE Field –
https://www.ietf.org/archive/id/draft-ietf-tcpm-accurate-ecn-20.html#section-3.2.2.4 – says:

"If AccECN has been successfully negotiated, the Data Sender SHOULD check the value of the ACE counter in the first packet (with or without data) that arrives with SYN=0. If the value of this ACE field is zero (0b000), for the remainder of the half-connection the Data Sender ought to send non-ECN-capable packets and it is advised not to respond to any feedback of CE markings. Reason: the symptoms imply either potential mangling of the ECN fields in both the IP and TCP headers, or a broken remote TCP implementation. This advice is not stated normatively (in capitals), because the best strategy might depend on experience of the most likely types of mangling, which can only be known at the time of deployment."

I would have imagined that the response where a data sender detects "Zeroing of the ACE Field" would be to simply fall back to using the AccECN options, rather than falling back to  sending non-ECN-capable packets, thus losing the benefits of L4S congestion control. Would that be feasible?

AFAICT a data sender can do just fine with zeroed ACE fields, as long as the data receiver is sending valid AccECN options.

I can imagine several different arguments for a response to "Zeroing of the ACE Field" that involves  simply falling back to using the AccECN options rather than disabling the sending of ECN-capable packets:

(1) The part of Postel's robustness principle that says "be liberal in what you accept" would seem to argue that a data sender should be liberal in accepting a zeroed ACE field as long as the AccECN options are intact and seemingly valid.

(2) For data senders that need to use TSO, but who have NICs where TSO necessarily corrupts the ACE field (due to RFC3168-style tweaking of the CWR bit that cannot be disabled), it would be advantageous to those data senders to be able to simply send zero ACE fields, rather than send ACE values that they know would be corrupted. AFAICT this could allow such senders to benefit from both TSO and L4S.

(3) Similarly, if a middlebox somewhere zeroes out the ACE field, AFAICT this could allow such senders to benefit from L4S in this case as long as the incoming AccECN options are intact and seemingly valid.

Thoughts?

thanks,
neal