[hristov]

Shameless plug:

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).

Yes, I am involved with this. If interested in testing, please send an email to the contact address in the website.

[geoffschmidt]

It's hard to evaluate your claim that ExtremeTCP is "the" solution, given that your website (1) does not compare your solution to the significant amount of literature and prior art in this space (eg, TCP Vegas, which is already implemented in the Linux kernel), (2) doesn't make any claims about friendliness to TCP Reno, which is the hardest part of retrofitting a new congestion control strategy onto the public Internet.

[hristov]

Good points. We do have comparisons with most existing TCP solutions out there (at least the ones we were able to get a hold of). I did not put them up because I did not want to drown people in information. But I should put up a white paper that has more detailed test results.

By the way we do beat the the Linux TCP stack (which now uses Cubic TCP, afaik). The data shown on the site is Compound TCP, which is the current windows implementation.

Let me know if you would like to see the detailed test results.

[reitzensteinm]

I would wager that the kind of people who are reading a website about TCP replacements are very much looking to be drowned in information.

Unless I'm mistaken, you're not yet at the stage where you're selling a turnkey solutions to pointy haired bosses.

[scott_s]

If you're going to claim "revolutionary new software," you will need a huge amount of information to convince people. Specifically, many experiments with detailed explanations of your methodology.

[sams99]

there is also http://www.fastsoft.com/home/ which professes to do the same, personally I worry about any non-documented non-public congestion control protocols, many years have been spent in the academia researching this subject ... it is easy to be "fastest" - just disable congestion control altogether - trouble is tons will break. In order for me to use a different congestion control algorithm in production I would need some experts to review the protocol to ensure I am being a good web citizen and not breaking the internet.

[hristov]

That is the initial reaction of most people. But it is not the case actually. If you disable congestion control, you will be the fastest for a little bit (maybe a hundred miliseconds) and then you will get drowned in dropped packets. In other words, you will be sending data fast but packets will start dropping on the way, so the data will not be received fast.

When we say we are the fastest, I mean we are the fastest at sending packets all the way through. This is not easy at all, and it is not as simple as sending packets as fast as possible.

We are very good at modulating our speed in order to have full speed while avoiding dropped packets. Thus, in many situations, we send data slower than other TCP versions but the other versions get into trouble and start dropping packets.

There is one universal rule for TCP congestion avoidance algorithms and that is that as soon as you notice a dropped packet, you have to stop and wait for the congestion to clear up. If you do not do that, you will break the internet. But we do follow that rule; furthermore, we avoid large numbers of dropped packets in the first place.

We have tested our software with other standard connections and it does play well with others.

As someone else noted, Fastsoft are respected by the industry and it is well established that they do not break the internet. We are about 30% faster than fastsoft.

[youngtaff]

Fastsoft have a good reputation amongst web performance people

[paulsutter]

There are many implementations of improved congestion control for TCP, several of which are implemented in the Linux kernel.

It's trivially easy to modify congestion control to get arbitrarily fast performance in high bandwidth-delay environments. I can tell you from experience that implementing fast performance in extremely lossy environments is harder.

And hardest of all is to come up with a solution that works on a network that is shared with the common congestion control implementations, and that works with billions of end nodes.

I spent years working on this. Feel free to reach out to me on my email address, I'd love to share with you my experience of commercializing such a product.