TCP congestion control is the algorithms that determine when to delay TCP packets and by how much, in the interest of getting maximum speed but not overloading

TCP congestion control is the algorithms that determine when to delay TCP packets and by how much, in the interest of getting maximum speed but not overloading routers and links. This is crucial to the survival of the Internet and to end-user experience, because without congestion control, everybody would send at their maximum rate all the time (subject only to the receiver's stated TCP receive window, which can be huge these days), and the Internet would collapse. Imagine sitting on a 2G connection in rural Africa, and the server at the other end blasts packets at 100 Gbit/sec on you. On the converse, imagine sitting at a 100 Gbit/sec connection, but the sender being overconservative and sending only at modem speeds... Basically, this is a really hard problem, since you can measure bandwidth only indirectly (and with much delay), and the changes you do will affect the measurements. Solutions exist in the form of reacting to packet loss (ACKs don't come back, or selective ACKs come back to explicitly tell you something was missing), to ECN (routers along the path setting bits in your header to explicitly tell you it's getting tight on bandwidth) and to changes in delay (as measured by ACK timing and embedded TCP timestamps; higher delay typically means you're building up a queue somewhere, which is bad). They also differ in what rate they start at (initial window), how aggressive and how they increase the rate when things appear to go well (exponential, linear, binary search), and how they decrease the rate when they get negative signals (cut in half, other tactics). An important factor is “fairness”, usually to TCP Reno (a classic congestion algorithm from the 80s); if you and another sender send at the same time down the same path and they use some other congestion control algorithm, you should get about half of the bandwidth each. (An algorithm that's too aggressive could easily cause the other side to lose packets and just keep decreasing its bandwidth estimate, crowding it off the link entirely.) A perfect congestion algorithm would immediately detect the correct amount of bandwidth (even in the presence of changing conditions and non-congestion-related packet loss such as a bad cable or Wi-Fi errors), send evenly at that rate, never send so much that packets are lost to congestion, never send so much that routers' queues build up and latency increases (bufferbloat) and be perfectly fair to all other algorithms. As for census; it's interesting to know what exists out there, what people are doing in practice, and what algorithms we need to compete against and be fair to.