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

[Sebastian Moeller <[e-mail]>]

Hi Koen,


so I see theoretical problem when a sufficiently paced ECN-unresponsive CBR-Flow with a rate above its commensurate share of the capacity gets placed in the L-queue (a configuration that is fully within the recommendations of the L4S drafts*). I think in that case the C-queue traffic is going to suffer. Arguing that this is not worse that with a single queue AQM is not really helpful, as:
a) a bog standard dropping AQM might make the CBR-flow respond
b) a single queue AQM ECN-enabled is not an option for L4S, exactly because L4S does re-define the meaning of CE (or better the appropriate response)

Mind you I have not tested that configuration and it hence is possible that coupling will push back sufficient "drops" into the L-queue to reign in the CBR-flow, but I think it will not and the C-queue is going to bear the brunt here. I would not be amazed if it will only be the weighted scheduler configuration that will limit how much capacity that CBR flow can hog.
This also shows that mismarking CBR-flows (or sufficiently paced but unresponsive flows) with ECT(1) on purpose will be a way to gain an "unfair" advantage on an L4S path. I am also not sure whether a perfectly paced flow would actually trigger the queue protection as currently (I would love for QP to detect and counter this behaviour**), but since that is optional anyway is is somewhat irrelevant whether it would help or not.





*) https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-l4s-id-24#page-22
The above section requires unresponsive traffic to be 'safe' to mix
   with L4S traffic.  Ideally this means that the sender never sends any
   sequence of packets at a rate that exceeds the available capacity of
   the bottleneck link.  However, typically an unresponsive transport
   does not even know the bottleneck capacity of the path, let alone its
   available capacity.  Nonetheless, an application can be considered
   safe enough if it paces packets out (not necessarily completely
   regularly) such that its maximum instantaneous rate from packet to
   packet stays well below a typical broadband access rate.

Our paced CBR flow only needs to stay/pace below "link capacity" to qualify here, that means that e.g. pacing at 80% capacity is well within this recommendation, but will not result in the advertised equitable sharing between the L and C queue.


**) Anybody willing to share data on this? Giving that Low-Latency-DOCSIS seems to implement all the required parts here, can somebody involved in the LL-DOCSIS effort share some insight, please?



> On Feb 25, 2022, at 10:28, De Schepper, Koen (Nokia - BE/Antwerp) <[e-mail]> wrote:
> 
> 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.