Re: [tcpm] A possible simplification for AccECN servers

[Mirja Kuehlewind <[e-mail]>]

Hi Bob,

Regarding the sentence:

"I just proposed respectively SHOULD and MAY, but I can now see there is no need to make that judgement call. However, it is still important to say an AccECN-enabled server MUST respond with either (0,0,1) or (0,0,0).”

This is a normative statement that is defined in RFC3168 and we should not state it here again but refer to RFC3168 instead.

Mirja



> On 25. Nov 2019, at 22:41, Bob Briscoe <[e-mail]> wrote:
> 
> Mirja,
> 
> 
> On 26/11/2019 01:02, Mirja Kuehlewind wrote:
>> Hi Jonathan,
>> 
>> Sorry I wasn’t clear. I think we should not have these normative requirement in the draft and change the text to make it non-normative. This section was meant to explain which modes you end up in and the current use of normative language doesn’t seem to be right to me.
>> 
>> Likewise the table was also not meant to say whenever you implement AccECN, you MUST negotiate it in the handshake. And likewise the table does not show any classic ECN only transitions.
> In the spec of AccECN, it's necessary and reasonable to state normative requirements for a node "that is AccECN-enabled". That doesn't mean that an AccECN implementation has to always support AccECN - it can always disable AccECN. But we do have to say what it is expected to do if it is following the AccECN protocol.
> 
> This draft has included that normative language for the negotiation phase in all 16 revisions since the first individual draft (that you wrote!).
> 
> The table shows only cases where one end or the other is AccECN-capable, and the text preceding and following the table gives normative requirements solely for the AccECN node(s) in those cases. It doesn't give any normative requirements for non-AccECN nodes.
> 
> In block 3, the server is AccECN capable, so in the AccECN spec. it's perfectly reasonable to say what it ought to do in response to various types of SYN. In particular, if it receives a SYN with AE,CWR,ECE=0,0,0 the AccECN-enabled server MUST respond with AE,CWR,ECE=0,0,0.
> 
> The only case that is in question, AFAIC, is whether we have to say what an AccECN-capable server does in response to a SYN from an RFC3168 client (AE,CWR,ECE=0,1,1). We need to somehow say an AccECN server can respond with a SYN-ACK that is either RFC3168 or non-ECN.
> 
> I just proposed respectively SHOULD and MAY, but I can now see there is no need to make that judgement call. However, it is still important to say an AccECN-enabled server MUST respond with either (0,0,1) or (0,0,0).
> 
> It's also important that the spec defines all three bits in the SYN-ACK responses, not just the 2-bits defined in RFC3168 - so that the combinations with AE=1 are ruled out and therefore remain available for future use.
> 
> 
> 
> Bob
>> 
>> Mirja
>> 
>> 
>>> On 25. Nov 2019, at 17:48, Jonathan Morton <[e-mail]> wrote:
>>> 
>>>> On 25 Nov, 2019, at 6:43 pm, Mirja Kuehlewind <[e-mail]> wrote:
>>>> 
>>>> I don’t think we can or should derive a normative requirement from this table. The table rather explains which mode you are in depending on the handshake that has happened. So it says: when client A is ECN capable and requests classic ECN support in the handshake and server B is AccECN capable and negotiated classic ECN support in the handshake then you are in classic ECN mode.
>>> I will merely re-quote the final sentence from my quoted text, which transforms that table into a normative requirement:
>>> 
>>>>      Therefore, as soon as an
>>>>      AccECN-enabled TCP server (B) receives the SYN shown, it MUST set
>>>>      both its half connections into the feedback mode shown in the
>>>>      rightmost column.
>>> - Jonathan Morton
> 
> -- 
> ________________________________________________________________
> Bob Briscoe                               http://bobbriscoe.net/
> 
>