Re: [tcpm] A possible simplification for AccECN servers

[Bob Briscoe <[e-mail]>]

Jonathan,

On 11/12/2019 19:58, Jonathan Morton wrote:
> The existing text in AccECN mandates falling back both halves of the connection to RFC-3168 mode if either end supports it but not AccECN, and the other end supports AccECN.  I supported moving AccECN forward (as EXP) with that language in place.  I would feel obliged to withdraw that support if the text were changed to make RFC-3168 support any less than a SHOULD at the server end and a MUST at the client end - noting that the definition of SHOULD is that a pretty solid justification has to be made for not following the point.
I think you are labouring under the common misconception that the IETF 
uses MUST or SHOULD language to advise implementers what the IETF thinks 
they ought to do. That's not the role of the IETF. MUST or SHOULD 
language tells an implementer who already wants to comply with an RFC, 
what is necessary or desirable to do to interoperate with others who 
also want to comply with that RFC. The initial decision on whether to 
choose to comply with an RFC is up to each implementer.

Don't worry, the AccECN spec says that the client MUST be able to 
fall-back to classic ECN support.

But it's not the IETF's role to tell an AccECN server implementer that 
they SHOULD fall back to classic ECN because that's not necessary for 
interoperation. All we need to say for interop is that an AccECN server 
that receives a classic ECN SYN MUST fall back to either classic ECN or 
non-ECN.

I've suggested some wording below to hint to implementers which choice 
they are likely to want to make. And I've only shown the ECN fallback 
case in the table, which is probably as much as many implementers will 
bother reading.

However, it would be an abuse of normative text to tell implementers 
they "SHOULD" make one of these choices - that's an improper use of 
"SHOULD" for evangelism rather than interoperability. We don't need to 
tell an implementer to act in their own best interests - they can work 
out for themselves that falling back to ECN gives better performance 
than non-ECN.

    3.  The third block shows the cases where the TCP server (B) supports
        AccECN but the TCP client (A) supports some earlier variant of
        TCP feedback, indicated in its SYN.

        When an AccECN-enabled TCP server (B) receives a SYN with
        AE,CWR,ECE = 0,1,1 it MUST do one of the following:

        *  set both its half connections into the classic ECN feedback
           mode and return a SYN/ACK with AE, CWR, ECE = 0,0,1 as shown.
           Then it MUST comply with with [RFC3168].

        *  set both its half-connections into No ECN mode and return a
           SYN/ACK with AE,CWR,ECE = 0,0,0.  This latter case is unlikely
           to be desirable, but it is allowed as a possibility, e.g. for
           minimal TCP implementations.

        When an AccECN-enabled TCP server (B) receives a SYN with
        AE,CWR,ECE = 0,0,0 it MUST set both its half connections into the
        Not ECN feedback mode and return a SYN/ACK with AE,CWR,ECE =
        0,0,0 as shown.



Bob

>
>   - Jonathan Morton
>

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