Re: [Ecn-sane] [tsvwg] Comments on L4S drafts

["De Schepper, Koen (Nokia - BE/Antwerp)" <koen.de_schepper@nokia-bell-labs.com>]

>> 2: DualQ can be defeated by an adversary, destroying its ability to isolate L4S traffic.

Before jumping to another point, let's close down your original issue. Since you didn't mention, I assume that you agree with the following, right?

        "You cannot defeat a DualQ" (at least no more than a single Q)


>> But that's exactly the problem.  Single queue AQM does not isolate L4S traffic from "classic" traffic, so the latter suffers from the former's relative aggression in the face of AQM activity.

With L4S a single queue can differentiate between Classic and L4S traffic. That's why it knows exactly how to treat the traffic. For Non-ECT and ECT(0) square the probability, and for ECT(1) don't square, and it works exactly like a DualQ, but then without the latency isolation. Both types get the same throughput, AND delay. See the PI2 paper, which is exactly about a single Q.

I agree you cannot isolate in a single Q, and this is why L4S is better than SCE, because it tells the AQM what to do, even if it has a single Q. SCE needs isolation, L4S not.
We tried years ago similar things like needed for SCE, and found that it can't work. For throughput fairness you need the squared relation between the 2 signals, but with SCE, you need to apply both signals in parallel, because you don't know the sender type. 
	- So either the sender needs to ignore CE if it gets SCE, or ignore SCE if you get CE. The first is dangerous if you have multiple bottlenecks, and the second is defeating the purpose of SCE. Any other combination leads to unfairness (double response).
	- you separate the signals in queue dept, first applying SCE and later CE, as you originally proposed, but that results in starvation for SCE.
	- you only can apply SCE less than CE, but that makes it useless, as it creates a bigger queue for SCE, and CE would kick in first anyway.

Add on top that SCE makes it impossible to use DualQ, as you cannot differentiate the traffic types.
So this is why I think L4S is the best solution. Why would you try an alternative if it cannot work?

Koen.



-----Original Message-----
From: Jonathan Morton <chromatix99@gmail.com> 
Sent: Thursday, July 4, 2019 4:03 PM
To: De Schepper, Koen (Nokia - BE/Antwerp) <koen.de_schepper@nokia-bell-labs.com>
Cc: Bob Briscoe <ietf@bobbriscoe.net>; ecn-sane@lists.bufferbloat.net; tsvwg@ietf.org
Subject: Re: [tsvwg] [Ecn-sane] Comments on L4S drafts

> On 4 Jul, 2019, at 4:43 pm, De Schepper, Koen (Nokia - BE/Antwerp) <koen.de_schepper@nokia-bell-labs.com> wrote:
> 
> So conclusion:   a DualQ works exactly the same as any other single Q AQM supporting ECN !!
> Try it, and you'll see...

But that's exactly the problem.  Single queue AQM does not isolate L4S traffic from "classic" traffic, so the latter suffers from the former's relative aggression in the face of AQM activity.  This isolation is the very reason why something like DualQ is proposed, so the fact that it can be defeated into this degraded single-queue mode is a genuine problem.

May I direct you to our LFQ draft, published yesterday, for what we consider to be a much more robust approach, yet with similar hardware requirements to DualQ?  I'd be interested in hearing feedback.

 - Jonathan Morton