Subject: [tcpm] draft-ietf-tcpm-accurate-ecn-08 inconsistencies?

From: Bob Briscoe <[email-masked]>
Date: Fri, 22 Mar 2019 09:39:25 +0100

Olivier,

Thanks for pointing out verbally last night at netdev that the spec 
states three different sets of valid values for the 'ACE' field on the 
SYN-ACK and the 3rd ACK of the 3WHS (with stateful or stateless handshake).

I promised I would check whether this was deliberate or an editorial 
mistake....

==SYN/ACK==
Valid values are 2,3,4 & 6

==3rd ACK==
By my reading, the valid values for the 3rd ACK are 2-7 and the draft is 
consistent in both stateful and stateless cases.
Please tell me if the text is not clear in some way that I cannot see.

==Ease of Implementation==
You also mentioned that the values chosen required an awkward set of 
case statements, just to check validity. Yes, there's a gap in the 
sequence - because value 5 (decimal) in the codepoint space on the 
SYN/ACK might have already been used (by RFC3540). However, the mapping 
was chosen to enable a simple algo to match them, and for the same 
function to be used for both SYN/ACK and ACK, as follows: (values shown 
in decimal)

IP ECN f/b
	ACE SYN/ACK 	ACE 3rd ACK
0
	2
	2
1
	3
	3
2
	4
	4
3
	6
	6

A pseudocode expression for the IP ECN f/b would be:
     bool server;            // pseudocode for "I'm receiving the ACK of 
my SYN/ACK"
     unsigned ip_ecn_fb, ace;
     ip_ecn_fb = ( (ace>1 ) && (!server || (ace & 0b101)) ) ? ace - ( 
(ace >= 6) ? 3 : 2) : RETURN_INVALID;

What's so hard about that? ;)

Bob

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

---

From: "Tilmans, Olivier (Nokia - BE/Antwerp)" <[email-masked]>
Date: Fri, 22 Mar 2019 10:47:37 +0000

Bob,

Thanks for looking it up.

The perceived difference I had was due to the notes 2/3 in table 3 in combination with the s.cep column which led me to believe that all values but 0 were acceptable for the final ACK of a statefull opening, whereas the syncookies case was stricter.

The ecn negociation status is embedded in the syn cookies, the 0b001 ACE is thus not needed/used to remember/identify that classic ecn was negociated (at least on Linux).

It should thus be possible to be more specific about what an AccECN server should do when receiving an ACE of 0b001 on the final ACK if it had an AccECN state for the connection/didn't find back the ecn bit in the syncookie: should it fallback to classic ECN? Disable ECN altogether as that is an error state? I doubt this can be safely ignored...
The draft doesn't specify it beyond 'it ought to be impossible'.

Best,
Olivier
________________________________
From: Bob Briscoe <[email-masked]>
Sent: Friday, March 22, 2019 9:39:25 AM
To: Tilmans, Olivier (Nokia - BE/Antwerp)
Cc: tcpm IETF list
Subject: draft-ietf-tcpm-accurate-ecn-08 inconsistencies?

Olivier,

Thanks for pointing out verbally last night at netdev that the spec states three different sets of valid values for the 'ACE' field on the SYN-ACK and the 3rd ACK of the 3WHS (with stateful or stateless handshake).

I promised I would check whether this was deliberate or an editorial mistake....

==SYN/ACK==

==3rd ACK==
By my reading, the valid values for the 3rd ACK are 2-7 and the draft is consistent in both stateful and stateless cases.
Please tell me if the text is not clear in some way that I cannot see.

==Ease of Implementation==
You also mentioned that the values chosen required an awkward set of case statements, just to check validity. Yes, there's a gap in the sequence - because value 5 (decimal) in the codepoint space on the SYN/ACK might have already been used (by RFC3540). However, the mapping was chosen to enable a simple algo to match them, and for the same function to be used for both SYN/ACK and ACK, as follows: (values shown in decimal)

IP ECN f/b
        ACE SYN/ACK     ACE 3rd ACK
0
        2
        2

1
        3
        3

2
        4
        4

3
        6
        6

A pseudocode expression for the IP ECN f/b would be:
    bool server;            // pseudocode for "I'm receiving the ACK of my SYN/ACK"
    unsigned ip_ecn_fb, ace;
    ip_ecn_fb = ( (ace>1 ) && (!server || (ace & 0b101)) ) ? ace - ( (ace >= 6) ? 3 : 2) : RETURN_INVALID;

Bob

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 22 Mar 2019 22:30:25 +0100

Olivier,

On 22/03/2019 11:47, Tilmans, Olivier (Nokia - BE/Antwerp) wrote:
> The perceived difference I had was due to the notes 2/3 in table 3 in 
> combination with the s.cep column which led me to believe that all 
> values but 0 were acceptable for the final ACK of a statefull opening, 
> whereas the syncookies case was stricter.
That is indeed what the notes mean.
That's why note 3 (forward compatibility for CU) applies to the 0b001 
case as well as Note 2 (stateless handshake).
>
> The ecn negociation status is embedded in the syn cookies, the 0b001 
> ACE is thus not needed/used to remember/identify that classic ecn was 
> negociated (at least on Linux).
OK. I'll write this for an implementation-generic case that doesn't 
preclude Linux.

>
> It should thus be possible to be more specific about what an AccECN 
> server should do when receiving an ACE of 0b001 on the final ACK if it 
> had an AccECN state for the connection/didn't find back the ecn bit in 
> the syncookie: should it fallback to classic ECN? Disable ECN 
> altogether as that is an error state? I doubt this can be safely 
> ignored...
You're right, I haven't given behaviour in all possibilities.

I think it might help to switch round notes 2 & 3, cos note 2 is more 
general than note 3. I've rewritten the notes as follows (in the 
authors' github copy for now):

    {Note 2}: If the server is in AccECN mode, these values are Currently
    Unused but the AccECN server's behaviour is still defined for forward
    compatibility.  Then the designer of a future protocol can know for
    certain what AccECN servers will do with these codepoints.

    {Note 3}: In the case where a server that implements AccECN is also
    using a stateless handshake (termed a SYN cookie) it will not
    remember whether it entered AccECN mode.  The values 0b000 or 0b001
    will remind it that it did not enter AccECN mode, because AccECN does
    not use them (see Section 4.1 for details).

    If a stateless server that implements AccECN receives either of these
    two values in the ACK, its action is implementation-dependent and
    outside the scope of this spec, It will certainly not take the action
    in the third column because, after it receives either of these
    values, it is not in AccECN mode.  I.e., it will not disable ECN (at
    least not just because ACE is 0b000) and it will not set s.cep.

I'm avoiding going any deeper, 'cos there's the two cases with & without 
ECN, then there's the sub-case with ECE feedback, yada yada.

Bob

Very few IETF protocols are designed for complete future compatibility 
like AccECN has been. I am hoping it will be used as an exemplar in future.

>
>
> Best,
> Olivier
> ------------------------------------------------------------------------
> *From:* Bob Briscoe <[email-masked]>
> *Sent:* Friday, March 22, 2019 9:39:25 AM
> *To:* Tilmans, Olivier (Nokia - BE/Antwerp)
> *Cc:* tcpm IETF list
> *Subject:* draft-ietf-tcpm-accurate-ecn-08 inconsistencies?
> Olivier,
>
> By my reading, the valid values for the 3rd ACK are 2-7 and the draft 
> is consistent in both stateful and stateless cases.
> SYN/ACK might have already been used (by RFC3540). However, the 
> mapping was chosen to enable a simple algo to match them, and for the 
> same function to be used for both SYN/ACK and ACK, as follows: (values 
> shown in decimal)
>
> IP ECN f/b
> 	ACE SYN/ACK 	ACE 3rd ACK
> 0
> 	2
> 	2
> 1
> 	3
> 	3
> 2
> 	4
> 	4
> 3
> 	6
> 	6
>
>
> Bob Briscoehttp://bobbriscoe.net/