Re: [tsvwg] Neal Cardwell's rationale for supporting ECT(1) as an input/L4S signal

[Jonathan Morton <[e-mail]>]

> On 13 May, 2020, at 1:29 am, Neal Cardwell <[e-mail]> wrote:
> 
>> They would if they tried to participate in a plain 3168 conversation,
>> right?  I don't see you can dislike SCE for that.
> 
> Yes, they would hit these issues if they tried to participate in a
> plain RFC3168 conversation, but I think that's somewhat academic,
> since they don't use RFC3168. I think the useful comparison is L4S vs
> SCE.

If you want to compare L4S to SCE, do it properly.

Look at the big picture.  How many existing, RFC-compliant networks does each proposal break?  How many of the ones that do break are RFC-ignorant to begin with?  How severe is the breakage; does it violate the principle of effective congestion control, or merely degrade gracefully to a more basic level of functionality?

Look at the data produced by both sides, not just one, and question why one set appears to contradict the other set.  Is there a difference in the focus of each set of tests?  Are they looking for the optimistic scenario, as desired for marketing, or for the pessimistic scenario, as required for real engineering?

Look at the arguments being presented.  Do they invoke appeals to authority, or fall into the sunk cost fallacy?  Or are they trying desperately to function as a meritocracy in an environment that seems strangely hostile to that concept?

>> How does it behave for L4S, without changing the datacentre hardware?
> 
> I think for the L4S case, the point is that the sender would mark the
> packets as ECT(1), even shallow queues in the datacenter switch would
> be marked as CE, the receiver would reflect the CE information, and
> the sender would see the CE but would know that the queue might well
> be shallow, so would not necessarily cut its cwnd by 50% (Reno) or 30%
> (CUBIC), until/unless the CE marks were sustained/prevalent.

So basically, from your perspective, it's fine to discard the existing ECN deployment in favour of making everything run DCTCP.  You will ignore all requests to negotiate RFC-3168, and only respond affirmatively to AccECN.  Welcome to the brave new world of L4S.  Safe as helicopters.  I'm *so* glad I'm a Beta.

What do you do about all those flows which, denied the chance to run ECN, have fallen back to packet loss as a congestion signal?  You still have the same problem of coping with their AIMD behaviour, and their application latency is increased by approximately one RTT every time they have to retransmit one of those lost packets.  So much for the L4S promise of "ultra low latency for everyone".

And what of everyone else who is already running, or thinking about deploying, AQMs and RFC-3168 ECN?  L4S throws a huge spanner into those works, which have taken twenty years to get moving to any appreciable degree.  Personally, I think the tipping point has been the development of AQM algorithms that are correctly configurable by mere mortals - a state of affairs to which I have contributed several years of my time.

There will be plenty of people who deliberately disable L4S support because their own network interacts badly with it - including everyone connecting over wifi.  I wonder what percentage of ordinary consumers even know what an Ethernet cable is?  SCE still offers reasonable performance to those users, and I'd be perfectly happy if they carried on using plain old ECN.  Any AQM at all is an improvement over a dumb, two-second-deep FIFO.

L4S still has too many problems - fundamental ones to which no robust solution has even been outlined - to commit the last ECN codepoint to.  I will freely admit that SCE also still needs work, but in some areas we are clearly ahead, and we make an effort to avoid over-promising.  We've had one year to get this far.  Given another year, what can we achieve?

 - Jonathan Morton