Re: [tsvwg] Related to "Non-L4S traffic abusing the L-queue" discussion during the interim

["De Schepper, Koen (Nokia - BE/Antwerp)" <[e-mail]>]

Hi David, Luca,

>> I'm just reading the draft and cannot comment on the code, but it would be intuitive that a coupled queuing systems of two queues would decouple when one of the two queues is empty.

The coupled probability MUST NOT take the L4S minimum queue size into account as it would indeed disable the coupling under normal conditions (the L4S queue is empty most of the time if there is more than 10% classic traffic).

Our Linux running code is checking the total backlog (from both queues) to disable drop, so only if the sum of bytes in “both” queues is less than 2 MTUs, drop is disabled, otherwise everything dropped/marked as defined by the AQMs, see: linux/sch_dualpi2.c at testing · L4STeam/linux (github.com)<https://github.com/L4STeam/linux/blob/testing/net/sched/sch_dualpi2.c#L273>. This is allowed of course, as it disables drop for all traffic before the coupling. The STEP marking on the other hand is only disabled when at enqueue more than 1 packet is in the L queue, see: linux/sch_dualpi2.c at testing · L4STeam/linux (github.com)<https://github.com/L4STeam/linux/blob/testing/net/sched/sch_dualpi2.c#L395>.

In the draft, the pseudo code does the >1 packet queued check only for marking L4S traffic with the L4S STEP/RAMP (see lines 5a-d in figure 7), not for the Coupled drop/mark (line 6 in figure 7) which is not impacted by that check.

Testing would immediately make it clear though that something is wrong as it would always give a high throughput to L4S traffic even with normal responsive L4S flows, leaving Classic responsive flows with little more than the 10% share given by the WRR. So it wouldn’t even work for responsive flows, so even if an implementation would never be tested for non-responsive flows: if the coupling works correctly for responsive flows, it will also work correctly for non-responsive flows.

If you think any corrections or additional (more explicit) text is needed to make sure people don’t mistakenly disable the coupled mark and drop when the L-queue is empty, let us know.

Thanks,
Koen.


From: tsvwg <[e-mail]> On Behalf Of Luca Muscariello
Sent: Saturday, February 26, 2022 12:16 AM
To: Black, David <[e-mail]>
Cc: tsvwg IETF list <[e-mail]>; Bob Briscoe <[e-mail]>
Subject: Re: [tsvwg] Related to "Non-L4S traffic abusing the L-queue" discussion during the interim

Hi David

I'm just reading the draft and cannot comment on the code, but it would be intuitive that a coupled queuing systems of two queues would decouple when one of the two queues is empty.

Reading the details of the pseudo code in the draft, if lq is empty p'L should be 0 and pL=pCL=kp' which may be !=0.

Additional text below the pseudo code provides details about a Linux implementation that marks packet IFF queue length is >= 2 MTU. Which may suggest that decoupling happens when the L queue is empty.

I did not check the code though.

I will read the document more carefully beginning of next week but I admit this part is ambiguous.

Luca

On Fri, Feb 25, 2022, 19:05 Black, David <[e-mail]<mailto:[e-mail]>> wrote:
Hi Neal,

So, I saw that explanation – could someone check the "running code" to make sure that the coupling and marking occur even when the L queue is always empty?

Thanks, --David

From: Neal Cardwell <[e-mail]<mailto:[e-mail]>>
Sent: Friday, February 25, 2022 12:58 PM
To: Black, David
Cc: De Schepper, Koen (Nokia - BE/Antwerp); tsvwg IETF list; Jonathan Morton; Bob Briscoe
Subject: Re: [tsvwg] Related to "Non-L4S traffic abusing the L-queue" discussion during the interim


[EXTERNAL EMAIL]


On Fri, Feb 25, 2022 at 11:56 AM Black, David <[e-mail]<mailto:[e-mail]>> wrote:
Koen,


I'll observe that "traffic that is not responding at all to CE marks" is not necessary to achieve the reported results if the experimental setup "prevents the L queue from seeing any
need to apply congestion signals, because it is always empty" as there would be no CE marks for the traffic in the L queue to respond to.

I think the key part here is "if". :-) The assertion "prevents the L queue from seeing any need to apply congestion signals, because it is always empty" is from:
  https://sce.dnsmgr.net/downloads/L4S-WGLC2-objection-details.pdf [sce.dnsmgr.net]<https://urldefense.com/v3/__https:/sce.dnsmgr.net/downloads/L4S-WGLC2-objection-details.pdf__;!!LpKI!2-aGvIgLG5_UcfoDdFo5NR6FegDlw6w7v97l7dT8g-Or7eBQNEgIITlBB4xE-wzo$>
That assertion is inconsistent with the functioning of the Dual-Q algorithm, as described in:
  https://www.ietf.org/id/draft-ietf-tsvwg-aqm-dualq-coupled-21.html [ietf.org]<https://urldefense.com/v3/__https:/www.ietf.org/id/draft-ietf-tsvwg-aqm-dualq-coupled-21.html__;!!LpKI!2-aGvIgLG5_UcfoDdFo5NR6FegDlw6w7v97l7dT8g-Or7eBQNEgIITlBB6qmUFY4$>

As Bob noted: "in the scenario shown, although the L queue is indeed always empty, it will see a high level of congestion signals (~10% in this case) via the coupling."
Here's Bob's e-mail for more context/details:
  https://mailarchive.ietf.org/arch/msg/tsvwg/joFr3sfOrxxkYhWdYrO2rLlCNUw/ [mailarchive.ietf.org]<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/tsvwg/joFr3sfOrxxkYhWdYrO2rLlCNUw/__;!!LpKI!2-aGvIgLG5_UcfoDdFo5NR6FegDlw6w7v97l7dT8g-Or7eBQNEgIITlBByEN3xHA$>

thanks,
neal



Please give that further consideration.

Thanks, --David (as an individual)

From: tsvwg <[e-mail]<mailto:[e-mail]>> On Behalf Of De Schepper, Koen (Nokia - BE/Antwerp)
Sent: Friday, February 25, 2022 4:29 AM
To: tsvwg IETF list; Jonathan Morton
Subject: Re: [tsvwg] Related to "Non-L4S traffic abusing the L-queue" discussion during the interim


[EXTERNAL EMAIL]
Hi Jonathan,

Can you confirm that this test is done with “Cubic” traffic that is not responding at all to CE marks? So it is just like any other non-responding traffic (like UDP CBR). We don’t see any other way to explain your results.

If so, we can/should remove this “issue” from the shepherd’s write-up, as such unresponsive flows will get the same throughput on any single-Q bottleneck with or without AQM (taildrop/PI2/PIE/CoDel/STEP/RED/…) with a latency that matches the AQM strategy.

Koen.


From: tsvwg <[e-mail]<mailto:[e-mail]>> On Behalf Of De Schepper, Koen (Nokia - BE/Antwerp)
Sent: Thursday, February 17, 2022 7:01 PM
To: tsvwg IETF list <[e-mail]<mailto:[e-mail]>>; Jonathan Morton <[e-mail]<mailto:[e-mail]>>
Subject: [tsvwg] Related to "Non-L4S traffic abusing the L-queue" discussion during the interim

Hi Jonathan,

It seems that the following open issue identified by the chairs:

Non-L4S traffic abusing the L-queue
• ‘DualQ gives a large throughput bonus to L queue traffic, ie. a “fast lane”’
• Is this a matter specific for DualQ that can be left for experimentation?

is based on the following experiment you performed:


>             simple two-flow competition test on a standard dumbbell topology,

>             with the bottleneck running a DualQ qdisc into a 50Mbps shaper.

>             Both flows were configured to use CUBIC congestion control with

>             ECN negotiated, but one was additionally tweaked to set ECT(1)

>             instead of ECT(0) on all data segments, and to pace its output at

>             40Mbps. This latter measure prevents the L queue from seeing any

>             need to apply congestion signals, because it is always empty.  These

>             tweaks allowed that flow to use 80% of the link capacity, gaining a

>             fourfold advantage over its competitor,

If there is capacity seeking traffic in the Classic queue, then it is even desired that the L4S queue does not add extra marks. The L4S marks should come only from the Classic coupling.
Before diving into details, can you first explain why in your experiment the coupling from the Classic Q has no effect on your paced and ECT(1) labeled Cubic flow?

I would expect that this ECT(1) labeled Cubic flow would get even less throughput than the Classic Cubic flow, as the first gets the doubled coupled CE marking probability (eg 2*10% = 20%) for L4S flows instead of the squared CE marking probability (10%^2 = 1%) which ECT(0) traffic would get.

Thanks,
Koen.