On Mon, Jul 25, 2022 at 10:42:37AM +0200, Michael Welzl wrote:
> Congestion can be defined as a state or condition that occurs when
> network resources are overloaded, resulting in impairments for
> network users as objectively measured by the probability of loss
> and/or delay. The overload results in the reduction of utility in
> networks that support both spatial and temporal multiplexing, but no
> reservation [Keshav07]. Congestion control is a (typically
> distributed) algorithm to share network resources among competing
> traffic sources.
>
> 11 years later, I still think this is reasonable.
>
> There is overload, which is undesirable; there is also underload, which is no
> less desirable. In between, there is an ideal state that CC algorithms aim
> for: 100% utilization at the bottleneck but no adverse effects for anyone.
> I would call this “saturation” or “full utilization” or something like that,
> but not “congestion”.
So what are the most wiedely accepted example numbers, and where to find them ?
E.g.: Typical internet path, N-router-hops, N=6 ?, no-queue RTT = e.g.: 10 msec.
With the typical worst-case available today TCP CC, absolute RTT under load =
? 1 sec ?
With the typical best-case available today, TCP CC, absolute RTT under load =
? 20 msec ?
And with those numbers, what percentage of utilization and goodput (utilization
minus retransmissions) do we have on the bottleneck link ?
Or thinking it from the side of Stuarts tool
Lets forget the user metric of RPM for a second: If its showing RTT under load
= 1 sec
for example, would it not be great if one could venture to guess
"With better (network congestion avoidance)? your RTT could be 20 msec"...
and maybe..
"and your throughput could be 10% higher"
(*) these numbers are extrapolations and provided only for illustration, no
guarantees.
Aka: If we know what well accepted performance results there are, it might
be possible to convert those into usefully communicated performance improvement
predictions to users, and then apply Stuarts "et the user know" approach to
create
uhm... "congestion" ? on the operators support phone lines to fix their
networks ;-)
One may argue that the no-load RTT/RPM numbers are already those
possible results with improved CC on the network, but i have not
seen anybody standing out and saying, "yes, that is widely agreed upon
research and measurement result". Instead i was above assuming for example
a doubling of RTT under load. And i am also not sure what we think the
impact on throughput would be. Stays the same. Fine. Gets somewhat lower,
that needs to be communicated upfront, gets better (reduction of waste by RTR),
great, should be used for marketing upfront.
Cheers
Toerless
