[tsvwg] FQ-CoDel response to unresponsive traffic (was: Related to "Non-L4S traffic abusing the L-queue" discussion during the interim)

[Bob Briscoe <[e-mail]>]

Dave,

I will keep reminding everyone that this shift of topic to FQ-CoDel is 
distracting from the task at hand:
     "Is Jonathan going to confirm that his 'throughput bonus' and 'fast 
lane' accusations against DualQ are baseless because his experiment was 
broken?"

Nonetheless, I've changed the subject line and responded on FQ-CoDel 
below, tagged [BB]...

On 25/02/2022 21:02, Dave Taht 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.

[BB] Surely CoDel code is meant to be robust to different deployments 
and configurations, e.g.
1. a VPN classified into one flow-queue:
     then an unresponsive flow within the VPN that is not a problem for 
the whole link could overwhelm the capacity being scheduled for the 
flow-queue
2. With this problem in CoDel, it should not be claimed that FQ-CoDel 
can be repurposed for one queue per user (e.g. for within aggregation 
networks)


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

[BB] Indeed, you often say you've "long thought" this. Pity you've never 
"short done" it ;)
Indeed, your primary concern about ECN only applies as long as "drop and 
mark" under overload is not implemented.

It should have been done when ECN was first added to CoDel, and it's 
still not done.
* The ECN spec [RFC3168; §7] has recommended it since 2001, so there's 
never been an excuse for not doing it.
* AQM Recommendations and Best Current Practice [RFC7567; §4.2.1] 
repeated this advice when the IETF first adopted it in Oct 2013:
https://datatracker.ietf.org/doc/html/draft-ietf-aqm-recommendation-00#section-4.2.1
     https://datatracker.ietf.org/doc/html/rfc7567#section-4.2.1


Bob

PS. The rest of the email strays off to yet another topic in the vein of 
'Bigger cages, Longer chains' Someone else might want to go there, but 
not me.

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

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/