FastTCP Commercialized Into An FTP Appliance

prostoalex writes "FastTCP technology, developed by researchers at CalTech, is being commercialized. A company called FastSoft has introduced a hardware appliance that delivers 15x-20x faster FTP transmissions than those delivered via regular TCP. Says eWeek: 'The algorithm implemented in the Aria appliance senses congestion by continuously measuring the round-trip time for the TCP acknowledgment and then monitoring how that measurement changes from moment to moment.'"

FastTCP is just a fancy name for TCP Vegas?

[Anonymous Coward]

FastTCP sounds like a fancy name for TCP Vegas (which has been around for quite some time). Window scaling and Vegas should buy you pretty much everything that FastTCP seems to be offering... Sounds like marketspeak to me.

Powered by handwavium

[Rix]

The same amazing material that makes these [wikipedia.org] so fast!

Re:hmm

[GWLlosa]

No, basically its just an optimization of packet rerouting and timing in hardware, instead of software. So its the same 'old' protocol, but with bits of it implemented in chips for speed, specifically the 'hey should I reroute now and it is ok to send a packet right now' bits.

Hype

[Zarhan]

Sounds like they just skip TCP slow start algorithm and stuff like that - so it's probably not faster than regular TCP after the window has stabilized. Slow-start and backoff algorithms of course cause slowdowns.

Other possibility is some sort of header compression.

Anyway, to use this safely you'd need to be *sure* you know your link charasteristics. The reason TCP has the slow-start mechanisms in the first place is to make sure you don't overflow the link - that's why it's known as flow control :)

Re:hmm

[stud9920]

No. TCP is end to end, the nodes in between could not care less (except for dubious filtering purposes) what layer 4 protocol is piggybacking upon IP proper.

Re:Powered by handwavium

[bockelboy]

Actually, FAST TCP is also available as a linux kernel patch. It's a well-tuned Caltech product which has been in development for years:

http://netlab.caltech.edu/FAST/ [caltech.edu]

Several highlights include:
- Caltech held the world record for data transfer for awhile
- Won the bandwidth challenge at SC05

It's one of the best ways to tune a single TCP stream. Finally, the list of about 50 TCP-related publications should indicate this isn't handwavium:

http://netlab.caltech.edu/FAST/fastpub.html [caltech.edu]

Traditional TCP streams (such as what you get with FTP) top out around 10-20 Mbps. If you want to see a single stream go a couple hundred Mbps, you need TCP tweaks like FAST (however, FAST is one of many competing TCP "fixes").

Re:To gain that much speed...

[Aladrin]

RTFA.

"The Aria 2000, which is due in July, supports 1G-bps links. Existing Aria appliances support 10M-bps links, 50M-bps links and 200M-bps links."

10gbps my ass. The one they haven't released only does a tenth of that. And the smallest of their products barely handles my home cable line.

For what it's worth, my initial thought was that they must be targetted truly massive lines and that it would be a lot harder to truly use those. Too bad it wasn't true.

Re:Hype

[Zarhan]

Oh, after reading other comments, I guess they really are going for solving the high-bandwidth high-latency link problems. I didn't even consider that to be necessary since I thought that was pretty much solved and as such, "old news".

ftp://ftp.rfc-editor.org/in-notes/rfc3649.txt [rfc-editor.org]

ftp://ftp.rfc-editor.org/in-notes/rfc3742.txt [rfc-editor.org]

I guess this device works as some sort of wrapper so that legacy TCP implementations don't get slowdowns, but doesn't strike as anything revolutionary to me - the RFCs are from year 2003.

Re:No Way

[maharg]

hmm, yeah, what I said - http://netlab.caltech.edu/pub/papers/FAST-ToN-fina l-060209.pdf [caltech.edu]

Re:FastTCP is just a fancy name for TCP Vegas?

[bach]

These slides http://www.fastsoft.com/downloads/Optimizing_TCP_P rotocols.ppt [fastsoft.com] refer to TCP FAST as a faster version of Vegas.

Those who fail to understand TCP..

[Junta]

Are doomed to reinvent it, poorly, to paraphrase a well known saying. I have to roll my eyes everytime I see someone recommend the use of UDP in a circumstance where the application will not tolerate data loss. In gaming and media streaming, UDP can make sense, where the receiver can gloss over the details and do something reasonable, to an extent possible interpolating the missing data or simply showing a corrupted block or having someone skip a little in an online game. The only places where I see UDP implemented in a context where packet loss without retry is tolerated is in traditionally embedded applications (i.e. service processors with IPMI, and TFTP in ethernet boot roms). Both of these protocols can start behaving very badly if packets are lost or if over a high-latency link.

TCP is the most researched most tweaked and most examined reliable transport protocol, and trying to reinvent your own over an unreliable protocol is asking for trouble.

Re:No Way

[Eivind]

Uhm, let me guess, your knowledge of TCP is based on Trumpet Winsock for Windows 3.11 ?

Modern tcp-stacks most certainly scale the window and certainly don't "mis-interpret" high latency as congestion. (they do however interpret high packet-loss as congestion, which is a reasonable guesstimate most of the time, but *DOES* break down on links that, for example, have a constant packet-loss of a few percent (regardless of traffic-levels)

Congestion Control

[pc486]

FastTCP isn't really a full TCP replacement but rather a congestion control algorithm. There are many competitors to FastTCP, including BIC/CUBIC (common Linux default), High-Speed TCP, H-TCP, Hybla, and many others. Microsoft calls their version Compound TCP (available in Vista).

If you use Linux, have (CU)BIC loaded, correctly setup your NIC, and tune your TCP settings (rx/tx mem, queuelen, and such) then there is be no way for FastSoft to claim a 15-20x speedup improvement. I've done full 10 gigabit transmissions with a 150ms RTT using that kind of setup. FastSoft's device doesn't even support 10 gigabit, and their 1 gigabit device still isn't released.

This article is nothing other than a Slashadvertisment.

TCP is underestimated...

[Junta]

I've seen arguments used where people say 'we don't need to worry about aspect X that TCP takes care of' and ultimately get bitten. IPMI to me is a good example. They have the notion of retries (more of an afterthought), and have sequence numbers above and beyond what UDP offers. The problem is that retries for most packets increment that sequence number, so a retry is indistinuishable from a reissuance of the same command. For some contents, this can be very undesirable.

When something with as much high-profile support as IPMI ends up with such shortcomings, it goes to show that people easily fail to understand why this aspect or that of TCP is not applicable to their use.

As to TCP over UDP, that's an example of a very bad sounding ideas. Redundant features of TCP and UDP. It's not as bad as TCP over IP over PPP over SSH which is over TCP (multiple reliable protocols on top of each other), but still, if you wanted to be a better TCP than TCP, the place to implement would be at the same layer, on top of IP protocol, not on top of UDP.

Re:So where's the SlowTCP?

[Andy Dodd]

QoS - typically implemented not in the TCP stack but in intermediary routers that prioritize packets (important stuff goes out first and is less likely to be dropped if the connection is saturated, "bulk" data like BitTorrent goes out only if the send queue is empty at the router's WAN connection and is most likely to get dropped if a queue fills up), and in some cases artifically throttle the connection by dropping packets if the sender transmits beyond a set limit.

If you're looking for QoS in a home environment, the easiest solution is likely to replace your router with one capable of running DD-WRT. (This assumes you have a "consumer grade" router. If your gateway to the outside world is a normal PC running Linux, it's just a matter of setting up QoS on that box... Quite a few HOWTOs exist for this.)

Re:hmm

[sudog]

.. yea, sure, they'd be great.. if they actually worked. Which they don't. If you have any non-standard device sitting in between a client and server which speaks a non-standard protocol, unless the device can guarantee that to each end there is in fact no modification of the traffic, that the device itself is completely transparent, the device is useless.

And I mean that: next time you implement one of these so-called miracle devices, run a TCP dump from both ends. If the TCP syn cookie is different, DO NOT INSTALL IT, AND RETURN THE DEVICE IMMEDIATELY.

Don't say someone didn't warn you.

I've spent the last four to six months debugging peoples' networks where it has invariably come down to these WAN-accelerators getting in the way and mangling network traffic.

*VERY* poorly implemented, to a one!

Re:No Way

[harlows_monkeys]

FastSoft's product may have been big news in the early 1990s, but if a company has to resort to making performance comparisons against the "Reno" TCP implementation, they're a snake oil salesman because Reno is such an obsolete and shitty TCP congestion control implementation

Well, let's see. They won the 2005 supercomputing bandwidth challenge with their system. They also have numerous publications in peer-reviewed journals, invited presentations at conferences, etc. Sure doesn't sound like snake oil.

The more things change...

[ta bu shi da yu]

... the the more they stay the same. [grotto11.com] And I quote:

"Many very stupid companies have tried to come up with overly clever ways to speed up TCP/IP. TCP, by its nature, is a stateful and bidirectional protocol that requires all data packets to be acknowledged; this makes the data flow reliable, by providing a mechanism for dropped packets to be retransmitted; but this also makes for a more strictly regimented flow structure involving more packets transmitted over the wire than in simpler, non-reliable protocols like UDP-- and therefore it's slower. One company that thought itself a lot smarter than it really was, called RunTCP, came up with the idea of "pre-acking" TCP packets; it would send out the acknowledgments for a whole pile of data packets in advance, thus freeing them from the onerous necessity of double-checking that each packet actually got there properly. And it worked great, speeding up TCP flows by a significant margin-- in the lab, under ideal test conditions. The minute you put RunTCP's products out onto the real Internet, everything stopped working. Which stands to reason-- their "solution" was to tear out all the infrastructure that made TCP work reliably, under competing load and in adverse conditions, in the first place. Dumbasses."

Re:No Way

[ostiguy]

Windows 2003 and XP still do not have rfc 1323 options enabled by default. This means a tcp window size of 2^32 bytes maximum, which is problematic for high bandwidth high latency links.