Re: [tcpm] A possible simplification for AccECN servers

[Mirja Kuehlewind <[e-mail]>]

Hi all,

Replying to Bob initial message because I have another point.

I need to double-check what the exact context of the sentence Bob mentions below is in the accECN draft but probably this should not be a normative requirement in this draft at all. I’m actually further not sure what exactly is meant with “support” in that sentence, but the question if a server replies to a RFC3168 SYN with an RFC3168 SYN-ACK is solely a question for RFC3168 and not AccECN.

Mirja



> On 23. Nov 2019, at 12:27, Bob Briscoe <[e-mail]> wrote:
> 
> tcpm-ers, Mirja, Richard,
> 
> draft-ietf-tcpm-accurate-ecn-09 currently says that an AccECN-enabled server MUST support both classic ECN and non ECN. However, that's not actually necessary for interoperability. Certainly, when an AccECN server receives a non-ECN-setup SYN, it MUST fall back to a non-ECN-setup SYN-ACK. But, if it receives an ECN-setup SYN, does anyone object if we change it from MUST to SHOULD respond with an ECN-setup SYN-ACK? And it MAY respond with a non-ECN-setup SYN-ACK?
> 
> Potential reasons for a server only supporting AccECN and non-ECN (which we can put in the draft):
> * lightweight server to minimize code complexity;
> * to allow for the possibility that AccECN clients might one day have widely replaced classic ECN, and some servers might choose to remove their classic ECN code to save having to maintain it.
> 
> 
> 
> FYI, the other way round, no such simplification of the client is possible. 'Cos there's no space for an AccECN SYN to say "I support AccECN but not ECN". So the client has to be able to support all three (AccECN, Classic ECN and non-ECN).
> 
> 
> 
> 
> Bob
> 
> 
> 
> -- 
> ________________________________________________________________
> Bob Briscoe                               http://bobbriscoe.net/
> 
>