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

[Neal Cardwell <[e-mail]>]

On Mon, Aug 15, 2022 at 9:54 AM Mirja Kuehlewind <mirja.kuehlewind=
[e-mail]> wrote:

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

Thanks, Mirja. Your proposed "NEW" text sounds great to me.


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

Agreed, it does leave that question open about when the AccECN option
feedback is reliable, but that's a more general question, and I agree your
text seems fine and it seems OK to leave the details up to the
implementation and further experimentation.

Thanks!

neal



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