Re: [tsvwg] Explaining my ect(1) as input to network position

[Sebastian Moeller <[e-mail]>]

Hi Koen,

I thought I would let this slide, but on second thought this raises more questions than it answers, so more below in-line.

> On May 12, 2020, at 13:18, De Schepper, Koen (Nokia - BE/Antwerp) <[e-mail]> wrote:
> [...]
>  
> I noticed that there are quite some “safety due to non-responsive TCP”-concerns raised again which were solved already. We have shown in the past that the Coupled DualQ responds to non-responsive traffic as a normal Single Q Classic bottleneck (with or without ECN). No fast-lane for L4S non-responsive traffic, only lower latency. Try sending 3 non-responsive UDP/CBR flows using each one of the non-ECT, ECT(0) and ECT(1) with each a sending rate of 100% link capacity into a DualQ. They will each get 33% of the link capacity, while pushing away all TCP traffic (no matter which ECT they are). Note that cumulative, L4S gets even only 33%, while Classic gets 66% capacity in this case! It shows again that the coupled AQM disables the scheduling and fully overrules its claimed “priority”-behavior. This is a very unintuitive concept of DualQ, that seems to be easily overlooked. Depending on the overload strategy, the Classic flows can experience 15ms extra latency compared to the ECT(1), but there won’t be throughput benefit. Do the same experiment on a correctly designed Classic ECN bottleneck and the behavior will be exactly the same (except for the latency benefit for ECT(1)). This sensitivity to non-responsiveness has been always the case, even now on the Internet you all are using. It is typically constrained within a single subscriber/user by per user scheduling.
> [...]

	[SM] I find this argument to be questionable on two accounts. Let me break down my issues:

1) Is this actually relevant? You are basically demonstrating fair sharing between multiple DOS streams. I severely doubt that anybody is considering that a priority goal for achieving fairness at. Just consider that all of your streams loose 66% of their packets, so it is quite doubtful that if those are truly data streams the user is going to be happy with the result.
	But what I really would like to see, is what happens if you add an additional ECT((0)-CUBIC and EXT(1)-TCP Prague stream to the mix. If these streams survive passage though your DOSed gateway, you might have more than a purely academic point. But as you concede TCPs will be severely impacted. 
	As an end-user this is exactly the situation where I would wish my upstream AQM to be flow-fair as that has a much higher probability of still delivering reasonable throughput for responsive flows. And yes, this can be fooled by spreading the DOS traffic over multiple 5-tuples, but that same spreading will also ruin the normal dualQ AQM and will also out-smart your proposed queue-protection design so L4S does just as bad as FQ in that situation and worse in the non-spoofed-sprayed context.
	Worse an enduser, on ingress, I will not be able to fix this problem post-hoc, as the non-responsive flows make L4S already evict the TCP streams and no amount of FQing on my side of the bottleneck can bring these already dropped TCP packets back. 

2) You seem to be relaying on the overload protection here, and the fact that your streams are both unresponsive and CBR (aka paced), if I understand the dual queue coupled AQM draft correctly your AQM basically regresses to being a computationally expensive head-drop system under those circumstances, and the fairness you describe above is a direct consequence if your three DOS sources using the same fixed data rates with an equal probability dropping AQM.

Best Regards
	Sebastian