Re: [tsvwg] What is "Scalable Congestion Control" in L4S?

[Sebastian Moeller <[e-mail]>]

Hi Ed,

I stumbled over the same previously, but the subtle issue is the formal definition is about marking rate in marks/second, while the second looks at marking probability as marks/packets over a time window, and while the marking rate stays constant the resulting marking probability will decrease with increasing packet rate. This is also true if marking probability is measured as marks/byte. However I fail to see a clear methods to deduce the relevant timewindow to calculate marking probability over.


> On 16. Apr 2024, at 10:25, Vasilenko Eduard <vasilenko.eduard=[e-mail]> wrote:
> 
> Hi all,
> 
> Both RFCs (9332, 9330) gives a formal definition that:
> "Scalable Congestion Control: A congestion control where the average time from one congestion signal to the next (the recovery time) remains invariant as flow rate scales, all other factors being equal."
> It is just a rate of the congestion signal, a simple matter.

[SM] Yes, this is marking rate in Hz.

> 
> RFC 9332 section 2.1 gives the impression that Scalable Congestion Control has more fundamental differences:
> "the steady-state cwnd of Reno is inversely proportional to the square root of p" (drop probability)
> But
> "A supporting paper [https://dl.acm.org/doi/10.1145/2999572.2999578] includes the derivation of the equivalent rate equation for DCTCP, for which cwnd is inversely proportional to p

[SM] But here this is marking probability which will depend on the actual data rate of the flow...

> (not the square root), where in this case p is the ECN-marking probability.

[SM] And that got me confused previously as marking rate and marking probability for a given data rate are proportional so I read p as a different way to say marking rate.

> DCTCP is not the only congestion control that behaves like this, so the term 'Scalable' will be used for all similar congestion control behaviours". Then in section 1.2 we see the BBR in the list of "Scalable CCs".
> 
> 1. The formal definition of "Scalable CC" looks wrong. At least it contradicts section 2.1.

[SM] Let's say that either description might be served well with explicitly describing the rate versus probability issue.

> 2. It is difficult to believe that BBR and CUBIC/RENO have so different reactions to overload signals because they both play fairly (starting from BBRv2) in one queue as demonstrated in many tests.

[SM] But they do differ... Traditional Reno will half its congestion window as a response to a dropped packet (or if rfc3168 is in use also as response to a CE-marked packet), while BBR will not do this... (older Versions of BBR will completely ignore marks and also try to ignore drops, newer versions of BBR will use a scalable response but still ignore drops up to a certain threshold). But these differences are not that relevant to BBR's sharing behaviour, as BBR determines its equitable capacity share via its probing mechanism and hence comes up with a decent response under similar conditions as reno, just based on different principles.

> It is probably impossible for such different sessions to share the load fairly if one session is reacting to p, but the other is reacting to the square root from p (p is the probability for congestion signal).

[SM] That is a true point, and that is why L4S requires a strict separation between the different response types and specific AQMs for each traffic type that take this into account.

Regards
	Sebastian

> 
> Best Regards
> Eduard Vasilenko
> Senior Architect
> Network Algorithm Laboratory
> Tel: [phone]
>