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,

The design goal of the DualQ is that the L queue is always empty as long as there is capacity seeking Classic traffic. If there is capacity seeking Classic traffic, it builds a Classic queue which is creating marks for the L4S flow too (don't forget the AQM coupling here!). If the sender is using falsely ECT(1) it would be marked even more than if it was using ECT(0), and back off even more if it was responsive. So this makes us conclude that the traffic in Jonathan's experiment was non-responsive (and not using Cubic) or CE marks were cleared or not echoed by the receiver, or ...?

One of the confusions is probably that the draft specifies only "starvation". As-is, it can be interpreted as being caused by senders, but in fact, the only starvation case we noticed is because of an implementation detail of how the classic queue measures the Classic delay. If the classic queue delay (or throughput measurement in combination with queue size) only happens when a classic packet is processed (scheduled), you need to use a WRR scheduler that processes a packet at least every update time (to get a new measurement value for the PI_update algorithm).

Another reason for using a WRR instead of a strict priority scheduler is that it improves responsiveness for sparse non-capacity seeking classic flows. You could call this a "temporary" starvation (in the order of 150ms which is how long the PI2 controller would need to reach the drop-ECN threshold, if the L4S flow has not responded based on the CE marks; BTW, it takes 240ms to reach 100% drop).

If you think it is useful/necessary we still can clarify this in the draft?

Koen.


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

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.

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.