[tsvwg] Not responding to ECN AQMs in the core (was: Related to "Non-L4S traffic abusing the L-queue" discussion during the interim)

[Bob Briscoe <[e-mail]>]

Sebastian,

I've changed the subject line, as you've changed the subject away from 
Jonathan's scenario.
See [BB] inline..

On 18/05/2022 14:28, Sebastian Moeller wrote:
> Hi Bob,
>
>
>> On May 18, 2022, at 15:09, Bob Briscoe<[e-mail]>  wrote:
>>
>> 	But did you test my scenario as well:
>> 1) home internet access link with fixed rate of say 250/40 limiting the maximum rate of a sender to 250
> 2) TCP flows with correct drop response but with an "artificial" (as in not actively negotiated between the endpoints) ECT(1) marking,
> 	so the flow(s) will respond to drop but will ignore CE-marks (after all the endpoints did not negotiate ECN usage)
> 	From the perspective of these flows congestion control is clearly not disabled.

[BB] So we're talking about a sender that sets ECT but doesn't respond 
to ECN markings. I don't know why you are so keen to be able to describe 
that as "Congestion control is not disabled," but I'll ignore that 
little quirk, just so we can get to the point...

> 3) traversing a backbone/peering/transit link with an active L4S-AQM where the total capacity is such that 250 is well below the L4S share (as expected from the relative scheduler weights for the two classes) but where the expected capacity of our flows under investigation is << 250 (that is where the operator of the link does not intend to give our flow(s) that much capacity).

[BB] To repeat what I think you are saying back to you for 
confirmation... I think you mean that other flows are filling the 
peering/etc link such that their throughput << 250Mb/s. But if the flow 
from the ECT1 source that is ignoring CE markings reaches 250Mb/s it 
won't exceed the point where the DualQ's WRR scheduler would limit the 
L4S class as a whole.

[And, just to be totally clear, I'm assuming you mean a DualQ Coupled 
AQM at the peering link (you said L4S-AQM, but the DualQ is not the only 
L4S-AQM).]

> To me it looks like these flows will now get close to 250 Mbps (that is they will be limited by the access links capacity) by ignoring the CE marks and not driving the L-queue or C-queue into overload and will push out other L4S and non-L4S flows to give up capacity. What am I missing here?

[BB] You're not missing anything in theoretical cases....

...except, in practice, network operators size backbone/peering/transit 
links such that under normal traffic conditions they are not the 
bottleneck. Which means that, when they /do/ become the bottleneck 
(which they can when traffic conditions are not normal), any individual 
flow will only have limited scope to outcompete the other flows in that 
core bottleneck before it becomes bottlenecked in its own access again. 
This is why network operators only deploy per-customer schedulers at one 
point for each customer - the access edge of the network. Put the other 
way, this is why network operators are willing to allow sender 
congestion control to share out the capacity of backbone/peering/transit 
links without a per-customer scheduler, even tho senders could disable 
their congestion control.

A numerical example explaining this is given in Appendix D of the tech 
report "Classic ECN AQM Fall-back 
<https://arxiv.org/pdf/1911.00710.pdf>". The appendix is titled "Core or 
Peering Link with Shared-Queue Classic ECN AQM". It goes on to show how 
most networks are designed so that even a core bottleneck caused by two 
anomalies at once gives individual flows little scope for outcompeting 
other flows.

> Mind you the same flow in the C-queue would respond to drops just as expected....

[BB] If the C queue supported RFC3168 ECN, a flow setting ECT0 but not 
responding to CE markings would outcompete other competing flows, 
whether L4S or Classic, just the same.

That's because this isn't an L4S-specific problem...

...If an RFC3168-ECN-capable shared queue is at the 
backbone/peering/transit bottleneck, any flow that sends ECT, but 
doesn't respond to CE markings will take more capacity than all the 
other responsive flows that it competes with (whether they are 
ECN-capable or not). And it would most likely fill its access link 
before driving the ECN AQM into overload (when it would start using drop 
on ECT packets). Again, the protection against extreme advantage here is 
the limited scope for advantage before the users that are taking 
advantage of the situation become bottlenecked by their own access capacity.

> If I understand correctly L4S-AQM at peering or in the backbone is one of the envisioned use-cases, so how is that not a problem, given that it typically should hold that
> edge access capacity << core capacity
> and also
> edge access capacity << transit/peering capacity

[BB] Because, as explained (in particular in the example referenced 
above), networks are sized to limit the scope for outcompeting other 
flows in a core bottleneck before the bottleneck for those flows shifts 
back to their access link.

>
> I think I have asked this question before, but do not remember the answer.
>
> Regards
> 	Sebastian
>
>
> P.S.: This just exposes the optimistic design of trusting an arbitrary marker bit instead instead of classifying flows by observed behavior.

[BB] The scenario you've given is equally applicable to RFC3168 ECN, and 
indeed, it is also applicable to non-ECN scenarios, where a sender does 
not respond to drops. The essence of the advantage is the 
unresponsiveness to congestion signals. And, when the bottleneck is in 
the backbone/peering/transit, the protection of the per-customer 
scheduler in edge access nodes is equally applicable whether the signals 
that are being ignored are L4S ECN, Classic ECN or drop.

You're trying to find scenarios where the DualQ does not become 
overloaded by unresponsive flow(s). In all those cases, responsive flows 
respond to congestion signals (whether ECN or losses) and unresponsive 
flows don't. Then you get unequal flow rates. That's not a new problem, 
it's 'just' the well-known advantage of unresponsiveness, which L4S 
doesn't change. And I've shown how networks are designed to limit the 
impact if it occurs at a backbone node.

It's only when the unresponsive flows drive the responsive flows to 
their minimum that the bottleneck starts to use loss to /shed/ load, 
rather than just to signal to responsive flows. That's why we ensured 
the DualQ detects this shift into overload state and starts dropping ECT 
packets.

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