Re: [tcpm] A possible simplification for AccECN servers

["Scheffenegger, Richard" <[e-mail]>]

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?

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

To be clear - I'd swap out the "Nonce" server to "Resrvd" or "Future"
(or SCE :) )...

Richard