Inline On Sat, Jul 23, 2022 at 08:10:43PM -0400, Stuart Cheshire wrote: > I feel that in retrospect the name “congestion control” was a poor choice. > Too often when I talk to people building their own home-grown transport > protocol on top of UDP, and I ask them what congestion control algorithm they > use, they smile smugly and say, “We don’t need congestion control.” They > explain that their protocol won’t be used on congested networks.
And we gave them a get-out-of-jail-free-card (which i won't repeat here, to make it not too obvious in case any such lazy home-grower listens ;-) > This is the problem of the terminology “congestion control”. When most people > hear the term “network congestion” they assume they know what that means, by > analogy to other kinds of congestion, like rush-hour traffic on the roads or > a busy travel weekend at the airport. They assume, by analogy, that network > congestion is a rare event that occurs on an occasional Friday night when > everybody is watching streaming video, and there’s nothing they can do about > that. They assume that congestion is the network’s fault and the network > should fix it by having have more capacity. And i thought those over-the-top-companies invented the term "it is always the networks fault". (which btw would let me rant about about the need for more visibility of end-to-end congestion state along the path, but i've given up on resisting the "everything that can must be end-to-end encrypted"). [long, good explanation cut] > Expressed that way, who wouldn’t want a transport protocol that works out the > best rate to send, to maximize the useful throughput it achieves? Everybody who has not fully elastic traffic. Pretty much all the classic non-IP traffic from non-packet networks that was put on IP (voice, video). A lot of it now has elastic replacements, but obviously, stuff like voice and video has a minimum bitrate below which it is unusable, and also a mximum bitrate above which it just produces waste (UHD on an apple watch anybody ? ;-). > 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. With that argument, fire and police departments have been ownsized, because their average utilization often really sucks. Most network use today is planned for peak utilization. Certainly all of streaming video is planned for fri-sun nights. I think i agree on what you're trying to get to, but its probably a bit harder to explain than you try to make it. > Given this, instead of continually having to explain to people that in the > networking context the word “congestion” has a particular technical meaning, > maybe it would be easier to pick new terminology, that is more easily > understood. Other terms that describe equally well what a congestion control > algorithm does might be “rate management algorithm”, “throughput optimizer”, > or “throughput maximizer”. "bandwidth sharing method", "resource sharing method" I like the second better, because when we start to figure out how to have more or less sub-RTT bursty traffic (such as in RMCAT), then we're talking about not only sharing bandwidth, but even more so buffers (and by implication latency) along the path. but yeah... also just throwing it out... nothing here jet that i feel would stick best. > When we talk to people designing a new transport protocol, it’s easy for them > to dismiss congestion control as uninteresting and unimportant, but it’s > harder for them to say, “We don’t have any rate management algorithm,” or, > “We don’t care about optimizing our throughput.” I guess i am still struggling with our ADs desire for "general purpose". If thats just the arbitrary elastic traffic flow with no low-latency/burstyness requirements, then "rate maximization" or the like would suffice. As soon as we bring anything more interesting in (ABR/DASH etc..) then it will IMHO become more difficult. But i do agree that we could do better marketing of our goals through better terminology. Cheers Toerless > > Stuart Cheshire -- --- [email protected]
