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

[Bob Briscoe <[e-mail]>]

David, it might help to be crystal clear, see [BB]

On 25/02/2022 16:55, Black, David 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.
>

[BB] If there's a Classic capacity seeking flow (as in this case), the 
coupling is designed to mark any L packets with the coupled probability, 
even if they are never queuing (e.g. if they are being paced). That is 
the normal way that the DualQ works, and has done for the last 10 years.

> Please give that further consideration.
>

[BB] No further consideration can be given to Jonathan's experiment, 
beyond that it was clearly broken in one of the ways we emailed to him 
on this list (17-Feb-22), without response so far.


Bob

> 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.
>

-- 
________________________________________________________________
Bob Briscoehttp://bobbriscoe.net/