Re: [tcpm] A possible simplification for AccECN servers

[Bob Briscoe <[e-mail]>]

Jonathan,

On 24/11/2019 13:20, Jonathan Morton wrote:
>> On 23 Nov, 2019, at 4:43 pm, Richard Scheffenegger <[e-mail]> 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 
half connections into the classic ECN feedback mode as shown in the 
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 
a SYN from a client in No ECN mode (AE,CWR,ECE = 0,0,0) it MUST set both 
its half connections into the No ECN feedback mode as shown in the 
rightmost column and return the SYN-ACK shown (AE,CWR,ECE = 0,0,0).


Bob
>
>   - Jonathan Morton

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