Hi ! Below:
> On 25 Jul 2022, at 14:19, Bob Briscoe <[email protected]> wrote: > > Michael, > > On 25/07/2022 09:49, Michael Welzl wrote: >> >>> On 25 Jul 2022, at 10:47, Carsten Bormann <[email protected]> wrote: >>> >>> On 25. Jul 2022, at 10:42, Michael Welzl <[email protected]> wrote: >>>> 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 this is all about “load control”? >> I like this! >> >> >>> Proper sharing of capacity is the other part of the function. >> Correct. (this comment made me think of additions to your suggested name >> above, but they just complicate it … “load control” is really nice IMO!) > > [BB] I'm afraid 'load control' doesn't work for me. It's better than > 'congestion control' because of the negative connotations. But 'load' implies > a slow aggregate average. The group is likely to be working on algorithms to > prevent queue spikes (eg. improving flow start-up, pacing segmentation > offload, etc), I don't think anyone would understand that's what the group is > doing if it were called 'load control'. > > My suggestion: congestion avoidance. > I remember Van Jacobson promoted this term in place of CC, when he last > appeared at the IETF to present CoDel. > Indeed, he wrote a paper that some might have heard of: "Congestion Avoidance > and Control" > (It's unfortunate though that CA was also given as the name of only one > phase of the CC.) > > The WG acronym could then be CALR, or perhaps even CAR (Congestion Avoidance > and Recovery). If AQM were also in the charter, I think that name would still > cover it. The CA and full CALR names still have the “but there is no congestion, so I don’t need this” problem. I think this problem is quite real, and has been, for too long. > BTW, I would also say that 'rate control' is not a brilliant name, 'cos it > doesn't include controlling delay once the rate saturates. The rate is an input, not an output. Throughput is an output. So the rate doesn’t “saturate” - it’s something to adjust based on measurable outputs (throughput, delay, …) I actually prefer Carsten’s suggestion over mine because it doesn’t have the problem that, as we have already seen, “rate control” sounds too much like “rate-*based*” control (i.e., not window-based). I don’t have a strong opinion about the exact term but I really do want the “I don’t see congestion, so this is useless stuff” problem to go away…. and this just won’t happen with CC, CA, CALR, .... Cheers, Michael
