TCP pretty obviously doesn’t suck as it’s pretty much powered the internet for the last 30ish (maybe more) years. I’m sure it isn’t perfect for every purpose and maybe I can be improved but enough with the click bait.
Coal power obviously doesn't suck as its pretty much powered the planet for the last 100 years.
It's perfectly possible for something to both be incredibly popular and to suck. An appeal to popularity is certainly not better than a click-bait headline.
I'd argue that most of the stuff we use sucks in some ways as well; suck isn't an absolute term. TCP sucks in very specific ways the article talks about.
It's not just popularity; it's an adaptable enough design to work in the range from 150 baud acoustic modem links to 40 Gbit fiber optics. Not many designs can withstand that, no matter how hard people try.
To my knowledge that has only ever been deployed to send ICMP messages, not TCP. With a TCP stack tuned to give more lenient timeouts it might work but you'll need a lot more trips to do a whole connection setup and teardown.
Complaining about the article’s title is no substitute for replying to the article’s content. Writing a provocative title is how you get people to read your article. If you have an opinion to share, you shouldn’t try to disguise it as a drab technical report. The article makes sound points and the title makes sense.
Compare “TCP Sucks” (easy to read—communicates, concisely, that this is an opinion piece, and what the opinion is)
or “Limitations of TCP” (misrepresents the article as informational)
The author says "TCP sucks", and is promoting his own protocol. Iridium. Which he hasn't even designed yet. That's a bit much. We don't get to criticize his approach.
(Also, if you're designing a communications system, don't give it the same name as another communications system.)
TCP has its limitations, of course. It was designed to work over a wide range of connections, including dial-up, and it does. It's suboptimal for broadband server to client connections where big server farms from a small number of vendors dominate. Hence QUIC and HTTP/2/3. Still, those don't provide a huge improvement in performance.[1] Even Google merely claims "on average, QUIC reduces Google search latency by 8% and 3.5% for desktop and mobile users respectively, and reduces video rebuffer time by 18% for desktop and 15.3% for mobile users." That's marginal. An ad blocker probably has more effect.
The author is worried about the overhead of the three-way handshake, but the overhead of setting up TLS is far worse.
If the title had been “Limitations of TCP for X” I would be more likely to read it than with its current title. For the simple reason that 9 out of 10 times, when people say “TCP sucks” they ignore all the things we ask TCP to do. Not least of which is “try not to break the Internet”.
I’ve tried to design stream transports on top of UDP. It is doable if the scope is narrow and you actually understand a bit of what went into other protocols (like TCP). But it isn’t easy.
It's perfectly possible for something to both be incredibly popular and to suck. An appeal to popularity is certainly not better than a click-bait headline.
I'd argue that most of the stuff we use sucks in some ways as well; suck isn't an absolute term. TCP sucks in very specific ways the article talks about.