FastSoft Tweaks TCP to Speed the Internet

Dr. Steven Low, a professor at the California Institute of Technology, has spent much of his life studying transmission communication control protocol (TCP), a technology that allows us to send emails, watch online videos and make Skype calls. TCP essentially makes the Internet (as we know it) work.

That same technology is the bedrock upon which Low (as CEO) and Cheng Jin (as VP of engineering) have built FastSoft, a Pasadena, Calif.-based startup with $4.3 million in funding from Miramar Venture Partners and Caltech. (The company is currently meeting with VCs in the hopes of raising a new round of funding.) The two-year-old startup has developed a device that sits between a router and the Internet (or any other wide area network) and ensures the faster, smoother delivery of data.

FastSoft’s technology can be filed under the general “Internet acceleration” category along with the tech sold by vendors like Cisco, Juniper and Riverbed Technologies. But FastSoft’s true competitors are in fact content delivery network providers such as Limelight Networks. Typically a CDN has points of presence across the globe that are wired together for the specific purpose of quickly delivering information, mostly by offering up information from POPs that are closest to the Internet surfer.

By comparison, FastSoft’s technology allows you to get the same results by serving up information to one location from another, regardless of how far apart they are, without going through an expensive CDN. This is one of the reasons why tiny the startup counts the likes of Honda, Post Group, Reuters Australia and apparently Getty Images (though I haven’t yet been able to confirm this) among its customers. It also just snagged Technicolor, which, like Getty, is building what amounts to its own digital asset distribution network and will use FastSoft to deliver big production files to remote locations.

One of my sources tells me that FastSoft is also working closely with Internap, a company that operates data centers and a CDN. According to some of the experts I spoke with last week, a partnership here could be a game-changer for data centers, since buying and deploying FastTCP would save them a ton of money on bandwidth, a big factor these days due to the explosion of online video.

What’s Wrong With TCP? Nothing, But….

In order to understand FastSoft (and FastTCP), one needs to step back and understand TCP, specifically how it works and what its drawbacks are: In data transmission, a TCP client receives a packet; it then sends back an acknowledgment of that packet to the sender. Once the sender receives the acknowledgment another packet is sent, and so on. At any given time, an untold number of packets can be mid-transit.

This stream, Low explained to me, is where problems can crop up. TCP is based on the additive increase/multiplicative decrease (AIMD) algorithm, which slowly increases the speed if delivery is going smoothly, but when packets start playing truant, decreases the rate of transfer by half — sort of like going from fifth gear to second, without the option of gradually slowing down. (See the sawtooth-like pattern in the accompanying chart.)

All of which is fine when it comes to lightweight files such as emails or plain web pages, but makes the transferring of large files such as videos clips painful. As FastSoft executives pointed out, a 30 percent reduction in throughput on a 10 Mbps DSL line can mean the difference between an HD movie experience and a standard definition one. A 50 percent slowdown on a high-capacity line, such as an OC-3 connection, means the speed capacity goes from 155Mbps to a mere 77.5 Mbps.

What Makes FastTCP Better?

The idea behind FastTCP, Low explained, was to overcome the shortcomings of AIMD. He and his fellow researchers found that if they measured the time it took to send and receive acknowledgments from receivers, along with tracking lost packets, they could overcome the problem of traffic overflows and make the transfers smoother.

To that end, FastSoft has developed a box called the E-Series Accelerator, which figures out the fastest way to deliver packets to the end destination without flooding the networks, thus restricting packet loss to a manageable level.

The system can also use intelligence to figure out if the packet losses are random or if there’s a major underlying problem, like network congestion, and take appropriate preventive measures. Getting back to my automobile analogy, it’s like having a speed radar and a live traffic feed along with the ability to smoothly downshift gears.

Why It Matters

One of the reasons I got so excited about FastSoft is because there’s no technology required on the recipient site, nor does there needs to be any change to the current TCP paradigm.

To be sure, nothing is a slam dunk. There are a lot of things that need to go right in order for this company to make it. And they will undoubtedly be asked to explain the logic behind putting yet another potential point of failure inside the network.

Low, however, is confident that the cost savings (by not paying big bucks to CDNs) on infrastructure and bandwidth, along with the ability to ensure the smoother (and faster) delivery of data, is going to convince large companies dealing with big digital files to try out FastSoft.

I’m not familiar with the technologies that you mentioned, but in general, routing is layer 3 and transport (e.g. TCP) is layer 4 (at least conceptually; I know there are exceptions in implementation etc), so they complement each other, in that one attempts to choose the best path from point A to point B and one attempts to make the most effective use of the chosen path.

The most remarkable ingenuity of the Internet pioneers, and one that is singularly responsible for the explosive growth of the Internet, is to have gotten the layering architecture right, of which the above is an example. Each layer provides a few functions well (media access, routing, congestion control & loss recovery, applications, etc) and each can evolve independently, unlocking innovations across almost all IT landscape and beyond. The very fact that multiple companies and industries are able to cooperate/co-exist/compete to build/operate/serve from/monetize on the same network infrastructure is an astounding testament of the architectural success of these pioneers, unimaginable before the Internet era. Can’t help but digress in awe…

In your post, you mention algorithms you’ve developed that optimally utilize available bandwidth and reduce packet loss etc. I know that Internap’s MIRO technology and smart routing does this when you purchase Internap bandwidth. Is your technology complimentary to Internap’s devices like the FCP box or would it replace it?

1. You are absolutely right that the idea of proxying a TCP connection is not new, and it is indeed an effective mechanism through which to address many issues that arise in massive infrastructures, as you pointed out. By inserting an appliance between the sender and the Internet, it gives us a way to deal with fluctuations in the Internet and maintain end-to-end application performance. The innovation here is not in convincing the sender to send fast, but the various algorithms to manage network fluctuations effectively to deliver robust performance to the clients. This include algorithms to optimally utilize available bandwidth in Internet, to be extremely resilient to packet loss, to maintain throughput, robustness, and fairness across long distances and heterogeneous receivers.

2. You are also right in pointing out that the basic TCP framework is intact in our approach. We have, however, completely re-designed the *implementation* of key functions in TCP that affect content delivery over the Internet, so that it is more efficient, robust, and evolvable in today’s networks and for today’s applications. We have implemented all these innovations in a way that is TCP-compliant – that’s why the appliance accelerates without having any hardware or software installation at the client side.

There is a far simpler, less math-vomit-inducing way to explain what they’ve done.

If you reduce the distance between the sender and the recipient you can increase the transmission rate. By introducing a box on the sender site that essentially gateways the SYN/ACKs other aspects of the TCP stream they have (or they should have) just convinced the sender to fire things off as fast as the wire can allow. They, in turn, manage the connection with the real client who is quite a longer distance (in terms of latency) away.

This is not new technology as far as I’m aware. I think I started doing thins like this back when running SYN proxies became the norm on massive application infrastructures.

Then again, I’m sure it’s a good speed tweak and makes a difference. I wouldn’t call it a new kind of TCP though. For that to happen, both sides have to be willing to talk differently. :-)