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

[Neal Cardwell <[e-mail]>]

On Fri, Feb 25, 2022 at 11:56 AM Black, David <[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
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

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/

thanks,
neal



>
>
> Please give that further consideration.
>
>
>
> Thanks, --David (as an individual)
>
>
>
> *From:* tsvwg <[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]> *On Behalf Of *De Schepper, Koen
> (Nokia - BE/Antwerp)
> *Sent:* Thursday, February 17, 2022 7:01 PM
> *To:* tsvwg IETF list <[e-mail]>; Jonathan Morton <
> [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.
>
>
>
>
>