Slashdot Mirror


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.'"

9 of 156 comments (clear)

  1. FastTCP is just a fancy name for TCP Vegas? by Anonymous Coward · · Score: 5, Informative

    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.

    1. Re:FastTCP is just a fancy name for TCP Vegas? by bach · · Score: 3, Informative

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

  2. Re:hmm by GWLlosa · · Score: 4, Informative

    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.

  3. Hype by Zarhan · · Score: 3, Informative

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

  4. Re:hmm by stud9920 · · Score: 5, Informative

    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.

  5. Re:Powered by handwavium by bockelboy · · Score: 4, Informative

    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/

    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

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

  6. Congestion Control by pc486 · · Score: 4, Informative

    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.

  7. Re:hmm by sudog · · Score: 3, Informative

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

  8. Re:No Way by harlows_monkeys · · Score: 4, Informative

    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.