Designing networking protocols that are robust in mathematical sense is unbelievably difficult. In fact, we humans have only found optimal solutions in a few cases if you dig through the mathematics literature. Many real-world networking protocol design scenarios do not have a known non-pathological implementation. Furthermore, there is a large number of decentralized protocol designs that we can prove to have many poor qualities. To bludgeon the equine, people that can significantly advance our understanding of such things tend to win Nobel prizes and similar. It is that difficult.<p>That said, TCP is not the best we can design given everything we know about designing network protocols. It was good enough for the people that designed it at the time, and possibly (my chronology is fuzzy) was approximately as good as the mathematics would have reasonably allowed when it was developed. We can make it work well enough in many cases -- the economics of inertia. Other narrow use cases are better solved differently but are not general solutions.<p>It is one of those problems that sounds like it should be easy to solve on the surface but turns into a bloody epic challenge once you start to dig into it. I am not offering a solution, just noting that very few people can.
Ok, maybe I'm missing something, but reading the article I see some weird ideas:<p>RED is hard to deploy, so let's change the base protocol instead. - how does that make sense? Everyone would have to start using new libraries and for backward compatibility we'd have to preserve the tcp layer too. That means standards like http would have to get extensions to use SRV records or suffer delays while utp availability is probed.<p>There's also a complaint that RED will drop packets once the queue is full. I don't get that at all - it will always happen...<p>In addition I get an impression there is some tension/implied superiority between us (people doing uTP) and them (ones doing RED). Why does it look so ugly? There's a known problem, there's an interesting solution for new software (uTP) and some plan to migrate old protocols transparently (RED). When did that turn into some bizarre conflict and why?
<p><pre><code> The solution is for the end user to intervene, and tell all
their applications to not be such pigs, and use uTP instead
of TCP. Then they’ll have the same transfer rates they
started out with, plus have low latency when browsing the
web and teleconferencing, and not screw up their ISP when
they’re doing bulk data transfers.
</code></pre>
That still doesn't address the problem when you have many users behind the same queue, some of whom care only about throughput and not latency. You need a scheme which will work when all of those users are acting selfishly.
If anyone is curious what uTP is, you can find the protocol defined here:
<a href="http://bittorrent.org/beps/bep_0029.html" rel="nofollow">http://bittorrent.org/beps/bep_0029.html</a>
The author seems to claim that is is implausible for a router vendor to sell a router that drops more packets.<p><pre><code> The marketing plan is that the because router
vendors are unwilling to say ‘has less memory!’ as a
marketing tactic, maybe they’d be willing to say
‘drops more packets!’ instead. That seems implausible.
</code></pre>
Yet he concludes by suggesting the router should drop all the packets.<p><pre><code> The best way to solve that is for a router to notice
when the queue has too much data in it for too long,
and respond by summarily dropping all data in the
queue. /snip/ Of course, I’ve never seen that proposed
anywhere…
</code></pre>
Based on his earlier reasoning, that would also be implausible.
It seems to me that on the IP level the net has been in a technological paralysis for some time.<p>We can't get RED or IPv6 deployed, and and the IETF doesn't seem to get anything useful happen these days.<p>edit: anyone else remember when layer 3 had a bright future ahead of it, IPv6 and end-to-end IPSec (with keys in the DNS) were just around the corner...
Having uTP running against UTP as an alternative network connection means is a rather unfortunate naming - I imagine a lot of people getting confused to the max, especially as it's pronounced the same. So pretty pretty please: Give the protocol a GOOD name first, then we're talking business! ;-)
I think the catchy title was meant to grab attention to an important present day issue.<p>But TCP actually does not suck, it's been there for longer than I have and served us pretty darned well up until now.<p>Never forget that when the TCP protocol was designed, the biggest concern we had was that a nuke would land on top of our heads at any minute and the network should keep working. Also, the "Internet" was thought to be a small niche network of networks among the military and academics.<p>I guess this is all well known, it's just my reaction to the editorialized title.
Just to be clear, "TCP Sucks", despite successfully running the majority of the global Internet traffic. "TCP Sucks" so bad we're basically going to copy a lot of it: window based congestion control, SACK, timestamps, ability to add new options, etc. "TCP Sucks" because it is not perfect and has an issue, an issue that requires router / switch upgrades. We're going to fix that by breaking backward compatibility with _tons_ of applications and requiring an OS update on _every_ client and/or application. All this assuming our relatively new and unproven thing is as good as TCP in all other ways and fixes this issue of TCP perfectly.<p>Hmmm. Me thinks that TCP does not suck so much.
Shameless plug:<p>Extremetcp.com is the solution to the congestion problems of TCP. The best part of ExtremeTCP is that it is not a new protocol. It is TCP. It just uses clever algorithms at the sender side to send data while avoiding congestion. (Since TCP does not actually specify which algorithms one should use as long as one avoids congestion, ExtremeTCP is a perfectly legal version of TCP).<p>Yes, I am involved with this. If interested in testing, please send an email to the contact address in the website.
I'm surprised he doesn't mention CurveCP. He's taken ideas from that author before (e.g. netstrings, which you'll find in the .torrent file format).<p>TCP does suck. If you try to use it for lots of short lived connections. And that pretty much sums up how it's being used nowadays, most the time.<p>For single, long term connections, TCP is fine.
> Of course, I’ve always used TCP using exactly the API it provides, and even before I understood how TCP worked under the hood gone through great pains to use the minimum number of TCP connections used to the number which will reliably saturate the net connection and provide good piece diffusion.<p>BitTorrent must not not have any books on copyediting.