Re: [tcpm] A possible simplification for AccECN servers

Hi,

I support the new text that Bob has suggested to allow a AccECN server
to choose to not support RFC3168 ECN.

I also support Rod's suggestion to replace references to "classic" ECN
with RFC3168 ECN.

However, as bob also pointed out, "ECT" is usually interpreted in the
context of the IP header, but the AccECN draft only concerns itself with
the TCP layer, where "ECN mode" / "non ECN mode" is the correct
description of the state of the TCP sessions feedback...

Best regards,
   Richard

Am 26.11.2019 um 02:49 schrieb Rodney W. Grimes:
> tcpm'ers:
>
>          I believe the more common terminology is "Not ECT" (Not
> ECN Capable Transport), rather than Non ECN.  Many new
> instances of "Classic" has crept in with the new text, which I
> do think we should avoid.
>
>          Comments inline marked [RWG].
>
> Regards,
> Rod
>
>> Jonathan,
>>
>> On 24/11/2019 13:20, Jonathan Morton wrote:
>>>> On 23 Nov, 2019, at 4:43 pm, Richard Scheffenegger <rscheff@gmx.at> wrote:
>>>>
>>>> My reading of bob?s suggestion is
>>>>
>>>> Syn - accecn
>>>> Syn-ack no ect
>> I think Richard meant 'no ECN' at the TCP layer, rather than 'no ect',
>> which implies the IP layer. I don't think this led to any confusion so
>> far on the thread, but I've corrected it in case someone else gets confused.
>>
>>>>
>>>> I don?t see any problem there ;
>>> That is indeed a valid transaction, but one which represents an AccECN client (that is, AE|CWR|ECE on SYN) and a Not-ECT server.  Of course, it is also legal by protocol to request RFC-3168 ECN (that is, CWR|ECE without AE on SYN) with a Not-ECT server.
>>>
>>> What the draft currently (and correctly, IMO) forbids is for an AccECN server to downgrade RFC-3168 clients to Not-ECT.  I don't see any reason for allowing this, because the difference in code complexity must be very small, and the benefit to the RFC-3168 supporting clients which are ubiquitous today (even if they don't always advertise it) in terms of avoiding packet loss and retransmissions just for the sake of a congestion signal is significant.
>> I also "don't see any reason for allowing this", but that isn't what
>> motivates text in RFCs. If there is no interoperability reason to
>> disallow such a downgrade, then we should not disallow it.
>>>
>>> It does appear that I missed part of Bob's proposal through trying to read it on a phone at the airport.  It made me think that he was proposing that AccECN *clients* might not support RFC-3168 as well.  I now see that he was proposing this only for servers.  I still think this is wrong-headed, but it technically doesn't break the protocol on the wire.
>> Yes, that's my point.
>>
>> If it doesn't break the protocol, it's not up to the IETF to tell
>> implementers what is "right-headed". The two examples I gave are
>> possible valid reasons an implementer might have (but even if no-one
>> could think of a valid reason now, there's no need to preclude this):
>> i) a cut-down lightweight TCP implementation
>> ii) an implementer wishing to rationalize the server code she has to
>> maintain when, in the long term future (recall that RFCs last for ever)
>> AccECN might have become pervasive and 3168 ECN hardly ever seen.
>>
>> Here's how I propose to alter the text:
>>
>> CURRENT:
>>
>>      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.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.
>>
>>
>> PROPOSED:
>>
>>      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 from a client in
>> classic ECN feedback mode (AE,CWR,ECE = 0,1,1) it SHOULD set both its
>
> classic -> RFC3168
>
>> half connections into the classic ECN feedback mode as shown in the
>
> ditto
>
>> rightmost column and return a SYN-ACK as shown (AE, CWR, ECE = 0,0,1).
>> The "SHOULD" allows for the unlikely case where a server might not wish
>> to implement classic ECN. When an AccECN-enabled TCP server (B) receives
>
> Ditto
>
>> a SYN from a client in No ECN mode (AE,CWR,ECE = 0,0,0) it MUST set both
>
> No ECN -> Not ECT
>
>> its half connections into the No ECN feedback mode as shown in the
>
> No ECN -> Not ECT
>
>> rightmost column and return the SYN-ACK shown (AE,CWR,ECE = 0,0,0).
>>
>>
>> Bob
>>>
>>>    - Jonathan Morton
>>
>> --
>> ________________________________________________________________
>> Bob Briscoe                               http://bobbriscoe.net/
>>
>
>> _______________________________________________
>> tcpm mailing list
>> tcpm@ietf.org
>> https://www.ietf.org/mailman/listinfo/tcpm
>