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

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

Hi Dave,

We are using the l4steam kernel, which was not that long ago upgraded and merged with the BBRv2 kernel which was 5.10. The code you referenced that does the head-drop when the queue is full is part of this code. You can see it in action because the sojourn time reduces when the arrival overload rate increases. At 200Mbps it is 600ms instead of the 1200ms expected with taildrop for a 10000p limit at 100Mbps. This is because the queue gets served at 200Mbps too, 100Mbps to forward and 100Mbps to drop at dequeue.

That code is not actually AQM code, rather taildrop which drops packets at the head. In the meantime (luckily in this case only after at least 100 seconds) the CoDel algorithm is dropping all non-ECT packets while still leaving the ECT(0) packets untouched. Since the queue doesn't shrink below 5ms, it stays dropping in this case, killing "all" non-ECT traffic. This is a "real" attack vector for (FQ-)CoDel and needs an immediate fix for all (FQ-)CoDel deployments. At the same time it can be upgraded to support L4S too ;-) and everyone is happy.

Regards,
Koen.

-----Original Message-----
From: Dave Taht <[e-mail]> 
Sent: Friday, February 25, 2022 10:06 PM
To: De Schepper, Koen (Nokia - BE/Antwerp) <[e-mail]>
Cc: Black, David <[e-mail]>; Neal Cardwell <[e-mail]>; 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

while I do not want to spend much time nitpicking this document...

"causing most of the time tail-drop" stood out. codel, fq_codel, cake all do head drop, and always have.

On Fri, Feb 25, 2022 at 4:02 PM Dave Taht <[e-mail]> wrote:
>
> I am happy to see some results of different scenarios here, and have 
> some suggestions as to others.
>
> On Fri, Feb 25, 2022 at 1:30 PM De Schepper, Koen (Nokia - BE/Antwerp) 
> <[e-mail]> wrote:
> >
> > Hi David,
> >
> >
> >
> > To be sure, we re-did the overload tests recently, confirming the 
> > previous overload results. These results are available at: Overload 
> > results caused by non-responsive UDP traffic for PIE, DualPI2 and 
> > CoDel AQMs | l4steam.github.io
>
> It really helps if you document what codebase you are testing. As one 
> example among many, fq_codel has a drop_batch facility now. An 
> enhancement to that has been, for 4? 5 years? is the codel count gets 
> incremented when drop_batch is hit.
>
> The article sets flows=1 for fq_codel, and then makes claims that it 
> has no overload protection. The "overload protection" is in the fq 
> portion of the algorithm. I have long thought were ecn of any form to 
> become a thing in the real world, that it would be best to also modify 
> codel to do "drop and mark" in the RTT seeking portion of the algo.
>
> Now, if you are trying to make the point that having a queue selector 
> that is kept from hop to hop and allows for differential treatment is 
> a win, I'd rather like to see results for a queue size that is 
> actually sufficient for pie/dualpi to operate at 10Gbit or above, 
> working at a mix of 10 to 60ms or greater RTTs. I assume the packet 
> limit for dualpi is 1000, shared between the two? What happens on this 
> test at queue 1000 at 10Gbit, or queue 10000 at 100Mbit? [1]
>
> In terms of future scaling issues for all these new forms of tcp and 
> qdiscs it would help if y'all (and by this I mean all parties here) 
> were testing 1gbit, 10gbit, and beyond traffic, at this point. The 
> default packet limit in codel is tuned to 10Gbit+, and has largely 
> been supplanted by a memory limit (as in cake) due to the prevalance 
> of gso/gro traffic.
>
> Also seeing the work on TCP BIG at google, how well is anything 
> working with 4k packets?
>
> [1] I've longed for a good rrul (simultaneous up/down) test on an 
> asymmetric network. 1Gbit down/50mbit up being common now.
>
>
>
> >
> >
> >
> > Specifically look at figure 8 at the end which shows that L4S traffic gets marks, up to 100% and appropriate drop if it reaches and exceeds the link capacity.
> >
> >
> >
> > The test case of Jonathan is approximated by the 70Mbps non-responsive ECT(1) UDP traffic on a 100Mbps link on a DualPI2 (Prague+Cubic) test case. In Jonathan’s case it was 40Mbps on a 50Mbps link. We also evaluated in extreme when sending at 100Mbps non-responsive ECT(1) UDP traffic on a 100Mbps link, and even exceeding at 140Mbps and 200Mbps. You will see the results are as if it is on a Single Q PIE AQM. Note also that CoDel which never drops ECT packets, causes actually close to starvation and high tail-drop delay results as shown in figure 1, even with ECT(0). So I guess all the concerns about FQ_CoDel and tunnels/Hash-collisions are equally severe and not related to L4S alone (can just be exploited by ECT(0) traffic today already!!).
> >
> >
> >
> > Koen.
> >
> >
> >
> > From: Black, David <[e-mail]>
> > Sent: Friday, February 25, 2022 7:04 PM
> > To: Neal Cardwell <[e-mail]>
> > Cc: De Schepper, Koen (Nokia - BE/Antwerp) 
> > <[e-mail]>; tsvwg IETF list 
> > <[e-mail]>; Jonathan Morton <[e-mail]>; Bob 
> > Briscoe <[e-mail]>; Black, David <[e-mail]>
> > Subject: RE: [tsvwg] Related to "Non-L4S traffic abusing the 
> > L-queue" discussion during the interim
> >
> >
> >
> > 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]>
> > 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]> 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]
> >
> > 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]
> >
> >
> >
> > 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/joFr3sfOrxxkYhWdYrO2rLlC
> > NUw/ [mailarchive.ietf.org]
> >
> >
> >
> > 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.
> >
> >
> >
> >
>
>
>
> --
> I tried to build a better future, a few times:
> https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org
>
> Dave Täht CEO, TekLibre, LLC



--
I tried to build a better future, a few times:
https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org

Dave Täht CEO, TekLibre, LLC