Re: [tcpm] A possible simplification for AccECN servers

[Christoph Paasch <[e-mail]>]

Hello,

> On Nov 25, 2019, at 9:12 AM, Bob Briscoe <[e-mail]> wrote:
> 
>  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). 

I support this proposed change for all the reasons that have been outlined by Bob and Neal.


Christoph


> 
> 
> Bob
>> 
>>  - Jonathan Morton
> 
> -- 
> ________________________________________________________________
> Bob Briscoe                               http://bobbriscoe.net/
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm