TCP Vegas
The first congestion control to measure delay instead of waiting for packet loss. Better in almost every way, and therefore unusable.
The 1994 idea was that a growing queue shows up as rising round-trip time long before anything is actually dropped. Vegas compares the throughput it ought to be getting, computed from the lowest observed round-trip time, with what it actually gets, and adjusts the window to keep a small constant number of packets queued. The result is low delay, few losses and steady speed. The problem appeared when it shared a bottleneck with the then-standard Reno: Vegas backs off as soon as the queue grows while Reno keeps pushing until something breaks, so Vegas starves itself. That insight — that a polite algorithm loses to an impolite one — is direct background to why BBR looks the way it does.