Re: [tcpm] A possible simplification for AccECN servers

[Jonathan Morton <[e-mail]>]

> 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 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.

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.

I should point out here that datacentres are a special case - a contained environment in which it is permissible to bend certain rules for the sake of performance, in ways that would not be acceptable for Internet traffic.  I think this is one of these cases, like DCTCP itself.

 - Jonathan Morton