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

[Bob Briscoe <[e-mail]>]

Olivier,

On 22/03/2019 11:47, Tilmans, Olivier (Nokia - BE/Antwerp) wrote:
> 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.
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...
> The draft doesn't specify it beyond 'it ought to be impossible'.
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 <[e-mail]>
> *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==
> 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 Briscoehttp://bobbriscoe.net/

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