Can you explain why there would be hundreds of competing TCPs?

I thought there were only a handful (Tahoe, Reno, Vegas, New Reno et al) of popular algorithms for the congestion control bit but it's all still TCP as specced in RFC 2581, no?

From where does all the complexity come?

Two laptops attach to a wi-fi hub connected to a DSL line provided by a major telco. One starts a large download. Why doesn't it completely monopolize the skinny straw that connects the 10+mb/s network it actually sees to the gigabit network beyond the DSL? Why can the second laptop start another large download and both see reasonable download speeds? At a more basic level, how do these TCP's even know how fast to drive the transfer? All they see is a multimegabit wireless network. They're not psychic, and there's no configuration box or DHCP setting for "256 kb/s dsl uplink".

That's what TCP actually buys you.

You can make a reliable UDP protocol with a few tens of lines of code. It's called "TFTP", and it's god-awful slow.

He probably means hundreds of competing TCP connections across a single link, which is common in the Internet (or in your LAN if you use BitTorrent).

This is an important distinction - the difference between production code that takes care of all of the edge cases that make things work in practice and the straight-forward implementation of the basic idea. But I think that's besides the point. The production implementations of TCP could probably be simpler and easier to understand if they were implemented in a similar manner as what's in this article.