Re: [tcpm] A possible simplification for AccECN servers

[Bob Briscoe <[e-mail]>]

Richard,

I'm responding to your email now, 'cos I'm just finalizing a rev of the 
AccECN draft. See inline...

On 12/12/2019 16:28, Scheffenegger, Richard wrote:
>
>
> Am 12.12.2019 um 15:53 schrieb Bob Briscoe:
>> You were saying we should just refer to RFC3168 in this case. I am
>> saying we should not refer to RFC3168 for the wire protocol aspect.
>> Rather we should specify the wire protocol part in the AccECN spec,
>> because we can specify more tightly than RFC3168 that only a 001 SYN/ACK
>> causes the client to fall back to classic ECN, whereas it would be an
>> X01 SYN/ACK if we referred to 3168.
>>
>> This was originally just a very minor disagreement about not referring
>> off to another spec, but it got detached from its original context by
>> the way the responses were posted.
>>
>> Here's suggested text. Changes from -09 are in green:
>>
>>     | AccECN | Nonce  | 1   1   1  | 1   0   1 
>> |(Reserved)              |
>>     | AccECN | ECN    | 1   1   1  | 0   0   1 | classic 
>> ECN            |
>>     | AccECN | No ECN | 1   1   1  | 0   0   0 | Not 
>> ECN                |
>>
>>
>>     2.  The second block shows the cases where the TCP client (A)
>>         supports AccECN but the TCP server (B) supports some earlier
>>         variant of TCP feedback, indicated in its SYN/ACK. Therefore, as
>>         soon as an AccECN-capable TCP client (A) receives the SYN/ACK
>>         shown it MUST set both its half connections into the feedback
>>         mode shown in the rightmost column.If it has set itself into 
>> classic ECN feedback mode it MUST then comply
>> with [RFC3168].
>>
>>
>> Note that I've referred to RFC3168 for the behaviour after the wire
>> protocol negotiation, but that's something I've been tightening up
>> separately from this conversation.
>>
>> Note that in the Nonce row, now that it's historic, I realized we
>> should've changed "classic ECN" to "(Reserved)", so as not to burn that
>> codepoint.
>
>
> A further comments here: Since Nonce is historic, should it even be
> mentioned as a possible server behavior at all, in this table?
[BB] All bit patterns are possible, whether or not there is a current 
RFC describing them. I always prefer to give a full truth table, to be 
clear what a machine does when it receives one of these bit patterns 
that might be used in the future.

Further, I think it's best to express this as in the snippet of table 2 
above, but also add to "Note 2" to say that the server response called 
'Nonce' in the table is now historic. I.e. the resulting mode is 
'Reserved', but the the pattern of bits from the server resembles that 
of the historic nonce behaviour.

>
> While the initial nonce sum was set to 1, and supposed to be included in
> the SYN,ACK, a mangling of IP ECN bits could conceivable have masked
> this (and a L4S sender, setting ECT1 on the SYN, would elicit the same
> SYN,ACK response from both a RFC3168 server, as well as a RFC3540 Nonce
> server...)
[BB] I don't think any of this is right. RFC3540 required the initial 
nonce sum to be 1. So NS on the SYN/ACK and 3rd ACK was always meant to 
be 1 (see end of S.5 in RFC3540).

At that time, the IP-ECN field of the SYN and SYN/ACK were meant to be 
Not-ECT, so no-one would even have thought of incrementing the nonce sum 
during the handshake, whether the IP-ECN field was different due to 
mangling, L4S or whatever.

>
> To be clear - I'd swap out the "Nonce" server to "Resrvd" or "Future"
> (or SCE :) )...
As above. Yes, 'Reserved' for the mode, but still 'Nonce' for host B, 
but add to the note to say "The server response called 'Nonce' in the 
table is now historic."



Bob
>
> Richard
>
>
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm
>

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