There’s another issue buried here, regarding the suggestion “throughput maximizer”.
People these days seem to care about latency much more than throughput. However, I think the fact that “low latency”, in the eye of the user, is often “maximized throughput”. E.g., web users experience “latency” not as a result of single packets being enqueued, but as a function of the flow completion time, which directly relates to the sending rate (in practice, mostly a function of IW, I suppose, and also shaved-off round-trips from 0-RTT conn. establishment and such). So … “throughput maximizer” or any term in this direction might be perceived as something less valuable than it is. I really think that “rate control” is the easiest and clearest way out… since, when it’s not somehow about controlling the transmission rate, it’s really not a CC mechanism. Cheers, Michael > On Jul 24, 2022, at 12:31 PM, Michael Tuexen > <[email protected]> wrote: > >> On 24. Jul 2022, at 02:10, Stuart Cheshire >> <[email protected]> wrote: >> >> On 30 Jun 2022, at 18:49, Martin Duke <[email protected]> wrote: >> >>> * The Transport ADs are going to consider chartering a new IETF working >>> group to update the administrative framework for congestion control >>> standardization, and potentially adopt any proposals that are sufficiently >>> mature for the standards track. We've formulated a proposed charter. Please >>> consider it a starting point for discussion. >>> https://github.com/martinduke/congestion-control-charter/ >>> I ask you to review this document before attending. It answers many of the >>> questions you may already have. >> >> I support this work. >> >> Congestion control algorithms apply to *any* flow of packets through a >> connectionless datagram network, not just TCP connections. >> >> While we’re considering starting this new work, I’m wondering if we should >> also consider a new name too. >> >> 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. >> >> 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. >> >> In reality, in the networking context, congestion control means sending data >> exactly as fast as the bottleneck link can carry it. If you send slower than >> the bottleneck link then you leave capacity unused, which is wasteful. If >> you send faster than the bottleneck link then the excess packets have to be >> discarded, which is wasteful. And the way that Reno or CUBIC do this is to >> occasionally send a little too fast, and then respond to the packet drops >> (or ECN marks) by slowing down. 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. If you >> upload a video to social media from your smartphone and your upstream >> Internet service is 10Mb/s, then you expect your smartphone to send at >> 10Mb/s. If you upgrade to 20Mb/s, then you expect your smartphone to send at >> 20Mb/s. If you upgrade to 30Mb/s, then you expect your smartphone to send at >> 30Mb/s. You expect your smartphone to drive your upstream link to the point >> of congestion and keep it there until the data transfer is complete. If it >> didn’t, you’d complain that you’re not getting the rate that you’re paying >> for. >> >> 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? >> >> 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. >> >> 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”. > Hi Stuart, > > I also support this work strongly and think a better name might help. > > However, there is one point which also could be considered when selecting the > name. > > I think your above model assumes that the sender is the only user of the > bottleneck > link and thus should fill it. But the bottleneck link could already be used > completely > and then another flow arrives. Then the rate controller should be aggressive > enough > such that all flows get an appropriate share. > > So "throughput maximizer", throughput considered only for a single > connection, might > be misleading. I guess we need some sort of "cooperative" or a similar term. > > I really think it would be good to have a protocol agnostic way of describing > CC > algorithms. Even for the price that it might be more complex than doing it > only > for a particular protocol. I'm willing to spend cycles on it. > > Best regards > Michael >> >> 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.” >> >> Stuart Cheshire
