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

[Sebastian Moeller <[e-mail]>]

Hi Koen,

interesting test, now it would be excellent to see how the 50 and 70 steps would look with queue protection active.


> On Feb 25, 2022, at 19:30, 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
>  
> 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,

	Is that actually true? fq_codel has a batch drop mode it employs to digg itself out of severe overload, see:
https://elixir.bootlin.com/linux/latest/source/net/sched/sch_fq_codel.c#L137
not sure this code path is avoided for ECT(0/1) flows, so on massive overload fq_codel will drop min(64, num_packets_in_fattest_flow * 0.5) from the "fattest" flow, in single queue mode that should still trigger... so yes, in normal operation fq_codel will not drop ECT(0/1) packets, but if push comes to shove it will do so in batches. If I read the code correctly this mode will trigger if during enqueue of a new packet either:
a) all queued packets exceed the memory_limit or 
b) there are more packets queued than limit
in both conditions fq_codel will drop packets in the fattest hash-bucket independent on the ECN bits.


> causes actually close to starvation and high tail-drop delay results as shown in figure 1, even with ECT(0).

	Yes, if you overload the queues you end up triggering the stress mode dropper, by adjusting limit/memory_limit you can tune this behavior closer to your liking. But even in stress drop mode it seems to do head drops. What evidence do you have for tail-drop? 

> So I guess all the concerns about FQ_CoDel and tunnels/Hash-collisions are equally severe and not related to L4S alone

	Yes, we know that the advantages of flow queueing disappear if flows can not be identified anymore... In this specific case though, fq-odel with multiple queues will do fine as long as the unresponsive flow will not manage to already crowd out the other flows before hitting the AQM bottleneck. In full fq-mode most of the fall-out of the unresponsive flow will be restricted to its hash-bucket (including innocent bystanders in the same bucket).


> (can just be exploited by ECT(0) traffic today already!!).


	Subtle difference, today in a FIFO or codel  our offending flow will see actual drops commensurate to its share of capacity, but in the L-queue all it will see are inconsequential CE marks, in other the words the L-queue delivers better service for hostile traffic. I do predict that this will be exploited if we actually deploy such systems, the question is when not if...
	I really do not think this is a good argument to make, if you go and introduce a scheduler into the network, it would be a wasted opportunity not to actually squash a whole class of abuse while at it, if all you claim is to not be worse than a FIFO, than you aim too low.

Sebastian

>  
> 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/joFr3sfOrxxkYhWdYrO2rLlCNUw/ [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.