On Mon, Jul 25, 2022 at 8:20 AM 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.) > Hmm, yes, I feel like I have heard of that paper somewhere... > 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. > IMHO "congestion avoidance" would be unfortunate because it only captures at most one half of the goal: the gloomier "don't go too fast" half, which is about avoiding causing excessive queuing delay and loss. But the other half is just as important: the happier "go as fast as you can" half: achieving high throughput for traffic. There is a balancing act here between two competing objectives, and "congestion avoidance" only characterizes one of those objectives. That's why I prefer variations on "rate control" or "rate management", since they are broad enough to encompass both the competing "don't go too fast" and "go as fast as you can" objectives. I also like Stuart's point that ideally we want a term that is broad enough to make it clear why every type of end host transport layer needs one of these algorithms, and "rate control" or "rate management" fit the bill there. > BTW, I would also say that 'rate control' is not a brilliant name, 'cos > it doesn't include controlling delay once the rate saturates. IMHO "rate control" is broad enough to include controlling delay, and in fact is broad enough to encompass all the objectives, including reducing delay, reducing loss, and increasing throughput. The "rate control" phrase merely says what the algorithm is doing, it doesn't spell out all the objectives (and doesn't spell out just the gloomy half of the objectives, as "congestion control" and "congestion avoidance" do...) More specifically, I think you and I agree that if you are in the scenario (common in datacenters) with more flows than the BDP of the path (in packets) plus the number of bottleneck buffer slots (in packets), then when you want to control delay once the rate saturates, you will need to use "rate control", aka pacing (pure window control by itself won't cut it). Any algorithm that purely uses window control will find scenarios where it won't solve the problem, and using the term "rate control" for the problem space will be a nice reminder of that. cheers, neal
