Re: [tcpm] A possible simplification for AccECN servers

["Richard Scheffenegger" <[e-mail]>]

Yes i think a tcp server in a DC accepting only accecn (possibly w/ option to switch to dctcp style reflection), and no-ect does make sense.

There is gear deployed already, which ONLY supports shallow ce marking - which breaks 3168 entirely. Behind such a switch, a server would be better off going only with non-ect (no ecn at all), or accecn. So that state transition should be allowed (and i think it is) by the accecn draft.

(Non-ect is classified into a different Q on the one example i could name, so no q sharing w/ drop class cc)

Gesendet mit der GMX Mail App

Am 24.11.19 um 06:20 schrieb Jonathan Morton

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