Re: [tcpm] A possible simplification for AccECN servers

[Bob Briscoe <[e-mail]>]

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/