Hi ! I wanted to separately comment on another aspect of this debate, from Stuart’s email. It’s this point (and I’m cutting the rest):
> If we define “congestion” as the bottleneck link being at 100% utilization, > then the job of Reno or CUBIC “congestion control” is to ensure that they > create “congestion” in the network. (..) > I would argue that “congested” is the desired state of a network (using the > term “congested” with its technical meaning in this context). Anything less > than “congested” means that data is not moving as fast as it could, and > capacity is being wasted. As much as I agree with a name change, I still disagree with this particular suggestion. The word “congestion” will always be interpreted as something negative, not desirable, and trying to re-define it won’t help. Indeed, defining 100% utilization as “congested” seems odd to me as a tech person as well. Many years ago, the ICCRG tried to arrive at a common definition of “congestion” and “congestion control”, which culminated in the following paragraph in RFC 6077: 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”. Cheers, Michael
