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

[Bob Briscoe <[e-mail]>]

Neal & Mirja,

Using the option without the ACE field is a possibility, but it has 
ramifications.
Below, first I will assume we are going to try to do this, then I'll go 
through the ramifications that I can think of, and see whether there are 
any show-stoppers.

But first, I suggest you take a look at my last response to Neal's point 
about hardware TSO offload, which I think was Neal's main motivation. If 
there is any misunderstanding there, it would be best to sort that out 
first.

On 15/08/2022 14:54, Mirja Kuehlewind 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.
>

[BB] That's not quite true - it's the other way round. We assumed that, 
once the AccECN Option passes the tests for mangling at the start of the 
connections, it has to be considered robust. Then the option is used as 
a consistency check for the ACE field (in case the option goes away and 
the ACE field alone has to be relied on). I mention this, for background 
on the ramifications later.

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

[BB]
1/ Can I suggest a rewording because we need to say what to do in either 
case.
NEW2:
If the value of this ACE field is zero (0b000), a Data Sender proceeds 
as follows:
     o If it has also not yet received any valid AccECN TCP options (or 
it has not implemented logic to process them), for the remainder of the 
half-connection it ought to send non-ECN-capable packets and it is 
advised not to respond to any feedback of CE markings.
     o If it has received a valid AccECN TCP option, it can continue 
sending ECN-capable packets, but it MUST ignore incoming values of the 
ACE field and rely solely on AccECN TCP options.
Note that, in either case, the decision of one Data Sender for one half 
connection is independent of the other.

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

[BB}

2/ Ramifications

There is the rather fundamental problem that the ACE field is used 
during the 3WHS to negotiate use of AccECN in the first place. So if it 
is established on the first SYN=0 packet in each direction that the ACE 
field is unreliable, can the ends be certain that what appeared to be a 
negotiation of AccECN during the 3WHS wasn't just an accident of 
mangling? Also the ACE field is used to check whether the IP-ECN field 
is mangled. So if the ACE field is unreliable, the check of the IP-ECN 
field could also be unreliable.

The protocol was based on the idea that the ACE field is in the main TCP 
header, so it cannot /not/ be sent, whereas AccECN options would be sent 
only when convenient. If end A deems that it is going to ignore the 
incoming ACE field, it has no way of signalling that to end B. So end B 
might adopt a policy of seldom sending AccECN Options or sending as few 
fields as possible. Whereas, if it knew the other end was solely reliant 
on them, it would send them more frequently, or with more fields.

Making such a fundamental change to the spec at this stage will require 
a very careful check of every word (I'm willing to do that, but I didn't 
before sending this email). There are likely to be all sorts of places 
that will become confusing unless wording is changed. E.g. right from 
the start it says ACE is essential and the AccECN Option is 
supplementary. Also an exception will have to be added to the section 
that Mirja mentions about consistency checking. And the rules for when 
to send an AccECN option (if sending them at all) might need to be 
changed. If they are changed, they will need to be tested with an 
updated implementation.

One more response to Neal below...

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

[BB] I do not envisage that AccECN code will allow a NIC to mangle its 
own protocol. The idea (described in the draft and implemented by Ilpo) 
is for initial implementations of AccECN to use software TSO as 
implemented in the kernel (and patched by Ilpo). I assume that there 
will be an API to determine whether hardware support for AccECN is 
available, so that AccECN implementations can use h/w offload when it 
is, and use s/w offload when it isn't. This will allow AccECN testing on 
a percentage of connections (for instance), while still doing h/w 
offload for the rest. The percentage of connections might be spread over 
all servers, or might be confined to a percentage of servers dedicated 
to offering AccECN support.


Bob

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

-- 
________________________________________________________________
Bob Briscoehttp://bobbriscoe.net/