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

hmm

[biscon (942763)]

Wouldn't you need to have FastTCP routers throughout the route in order to reach the speed mentioned?
and if so why bother using the old FTP protocol instead of just making a new and more modern protocol?

Re:hmm

[GWLlosa (800011)]

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.

Re:

[Courageous (228506)]

Honestly, I don't know what all the hooplah is about. We've known for ages about the impact of latency and its interplay with windowing on thruputs.

I'm more excited by the new class of devices that are acting as block-caches for generalized TCP/IP traffic. These things are really neat-o for large distributed organziations, because they really help with duplicate traffic of which there is typically LOTS in every large organization. Idea is very simple:

Devices sit at each WAN end point, transparently inserted

Re:hmm

[sudog (101964)]

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

[profplump (309017)]

Most routers -- particularly those on the public Internet -- route only at the IP level and not at the TCP level. As such they would not notice anything different about these packets.

Re:hmm

[stud9920 (236753)]

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:

[multipart/mixed (163409)]

No.

Al Gore didn't invent the Transmission Control, he invented the Internet.

Hence, data centers today mostly use Internet Protocol routers.

All Hail Al!

Re:hmm

[Citizen of Earth (569446)]

Al Gore didn't invent the Transmission Control, he invented the Internet.

Al Gore never claimed to invent the Internet. That's just a Republican spin on relatively accurate statements that Gore Made. What Al Gore invented is Algorithms. That's why they are called that!

No Way

[hardburn (141468)]

Regular TCP can't be more than an order of magnitude away from the Shannon Limit, can it?

Re:No Way

[maharg (182366)]

The problem is that "regular" TCP mis-interprets long Round-Trip-Time (aka latency) as link congestion and backs off the rate at which it is sending packets.

The bandwidth between point A and B may be rated at a high throughput, but TCP protocols such as FTP will never achieve that speed if the RTT is long. Increasing the bandwidth won't help !! So a slowdown of 20-30x is not uncommon on WAN links with high latency e.g. transcontinental, via satellite.

I've looked at technologies like Digital Fountain (and it's Java implementation, FileCatalyst) which use UDP and some clever mathematics to overcome latency, however it's not clear from TFA what FastTCP is doing underneath..

Re:No Way

[maharg (182366)]

.. although I keep coming back to the sentence "...senses congestion by continuously measuring the round-trip time for the TCP acknowledgment and then monitoring how that measurement changes from moment to moment.".

I would imagine in the typical high-latency scenario, where regular TCP is mis-interpreting long RTT as link congestion, and backing off the rate, FastTCP is able to actually keep pushing the rate up, meanwhile keeping an eye on the RTT. I mean, the RTT shouldn't increase in line with the rate, unless the link actually *is* congested. So just increase the rate until the RTT increases, at which point you are genuinely maxxing out the link. I think that must be how it is working..

Re:

[maharg (182366)]

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

Re:

[644bd346996 (1012333)]

Windows is still highly sensitive to high latency. Try running a bandwidth test with a nearby server and one across an ocean. You'll notice a much bigger difference with Windows than with a stock modern UNIX, which can still be tweaked quite a bit.

Re:

[ostiguy (63618)]

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.

Re:No Way

[Andy Dodd (701)]

It doesn't, unless your TCP implementation is from the stone age.

I love how fastsoft likes to compare themselves to Reno. 4.3BSD "Reno" was released in 1990, and the classic Reno implementation is LONG obsolete (and does indeed suck on a wide variety of connections).

I can see how it would be quite easy to achieve 10-20 times the throughput of Reno on a high-loss or high-latency connection, in fact a stock untuned Linux stack will do so in many situations. (For example, a few months ago I was doing TCP throughput tests dealing with some faulty hardware that liked to drop bursts of packets due to a shitty network driver. A machine running VxWorks 5.4, which is pretty much vanilla Reno, could only send 160 kilobytes/second over a 100Base-T LAN to that machine due to the packet loss making it throttle back. An untuned laptop with Linux 2.6.20 managed 1.7 megabytes/second over the same connection to the same destination.)

High latency connections were a major problem for TCP prior to RFC 1323 were a problem, but TCP stack authors have had 15 years to implement RFC 1323.

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.

Re:No Way

[harlows_monkeys (106428)]

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.

Re:

[Eivind (15695)]

It doesn't, in general. There are edge-cases.

For example, most tcp-implementations use slow-start, which mean they will, regardless of latency, start with a small window, and then if that goes trough, gradually increase the window-size until no improvement is experienced anymore.

This makes a huge difference for example if your application transfers many small files, each over its own tcp-connection, which FTP will do but which I'm aware of no other commonly used file-transfer application doing. It's no

Re:No Way

[Stellian (673475)]

Shannon-shmannon. How dare you !
If you've read TFA you'll know this revolutionary technology not only increases the speed by a factor of 15 to 20 times, but also insures "overall client happiness". Amazing !

Re:

[PDAllen (709106)]

Basic TCP simply ramps up the transmission rate linearly until it starts dropping packets (timeout for receiver acknowledgement), then it halves the rate and begins to ramp up again. So that means that if there is a decent amount of capacity (i.e. the receiver can ack the packets in time) then you expect to get at least half the speed the data protocol allows (this too isn't perfect but again it's not too far from Shannon). There are fiddles to deal with low capacity channels, which are pretty standard. The

FastTCP is just a fancy name for TCP Vegas?

[by 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.

Re:

[bach (4295)]

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

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

[jollyreaper (513215)]

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.

You wouldn't want to use TCP Vegas, the packets are unroutable. What happens in TCP Vegas stays in TCP Vegas.

Powered by handwavium

[Rix (54095)]

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

Re:Powered by handwavium

[bockelboy (824282)]

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

Does it speed up ftp or TCP/IP

[the_womble (580291)]

Does this speed up FTP or TCP?

If the latter can it speed up other protocols?

Hype

[Zarhan (415465)]

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:

[Zarhan (415465)]

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.

Nonsense

[gweihir (88907)]

Typical FTP connections get 80% or so of available bandwidth. 15-20x faster is not possible. Maybe 1.2x if you re lucky.

Re:Nonsense

[MindStalker (22827)]

Only for short lengths. For international or especially satellite connections you get less than 10% with normal TCP.

Re:

[gweihir (88907)]

Which still does not matter, since yous last mile is typically a lot slower than the international connection. Anyways, I get far more than 50% of my last mile (1MBps) routinely with FTP.

Re:Nonsense

[bockelboy (824282)]

Think again. I suspect that you only have tried that on a low-speed link (DSL, Cable, FIOS, etc). Try thinking about 2 orders of magnitude faster.

I transfer about 20 TB / day at work, and that wouldn't be possible with a "typical FTP connection".

If you read the papers coming out of Caltech, you'd see they were optimizing for 10 Gbps lines, not residential lines. 15-20x faster is a very fair estimate; look at Caltech's presentations at SC05 or SC07.

Re:Nonsense

[bockelboy (824282)]

It works fine, but we actually tend to lean toward many streams as opposed to uber-fast single streams.

Truthfully, you have to tweak the system pretty hard to get decent performance over a single stream (for us, 155 Mbps isn't sufficient - I work on a LHC project), especially from Nebraska to Switzerland (CERN). FAST TCP helps out a whole lot. GridFTP is the other piece of the equation - it is basically FTP with multiple data streams.

We tend to lean on hundreds of streams a whole lot more than tweaking TCP settings, and the Caltech guys give us heck for that. They're right, however - if you're getting 100s of KBps per stream to some European site, it just takes a ridiculous number of streams to get up to 100 MBps. Right now, the storage systems are behind the network, so we haven't even been able to start playing with FAST TCP yet.

http://cmsdoc.cern.ch/cms/aprom/phedex/prod/Activi ty::RatePlots?graph=quantity&entity=dest&src_filte r=&dest_filter=Nebraska&no_mss=true&period=l14d&up to=&.submit=Update [cmsdoc.cern.ch]

To gain that much speed...

[Aladrin (926209)]

To gain that much speed, your network must be really fscked up. I can max out my 7mbps line on any FTP that has the bandwidth available. I've heard of people lines much much bigger than mine that max theirs our regularly, also. I'm not talking about short hops, either... I mean international.

The only way I could see this as being possible is if there is so much latency that it basically makes the TCP protocol think every packet is lost, and resends them... 20 times. If you are seriously on a network t

Re:

[maharg (182366)]

Not so. High (>1500ms) latency *severely* affects TCP protocols like FTP. I encounter this on trans-continental WANs which go over satellite every day. I've tried some UDP compression such as FileCatalyst, and 15-20x speedup is possible on some links.

Re:

[bockelboy (824282)]

Hi -

You're thinking way too small. FAST TCP was designed with 10 Gbps links in mind - i.e., Internet2 type applications. FAST TCP streams are able to achieve several hundred Mbps. FTP streams over TCP Reno usually max out on something relatively pathetic, like 10-20 Mbps.

Caltech's SC07 presentation showed commodity servers which could transfer 2 Gbps end-to-end using their FDT tool (Java based, actually). The servers had 4 HDDs, dual Gigabit ethernet conncetions, and ran a Linux 2.6 kernel with the FAST

Re:

[Aladrin (926209)]

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:

[Aladrin (926209)]

You should probably bother to RTFA then.

"Beta testers at The Post Group, a film post-production facility in Hollywood, Calif., found that the Aria delivered 15 to 20 times faster transmissions "and better overall client happiness," said CIO Darin Harris."

For single connection use of big pipes

[Animats (122034)]

This is for single-connection use of wide-bandwidth channels with long latency. If you're synchronizing two servers across a considerable distance and have more than 1Gb/s or so available, it might be useful. For anything less, don't bother.

For local connections, you don't have many packets in flight, so you don't need this. For slower connections, you don't have the bandwidth to get that useful many packets in flight, so it doesn't help there either. It's not going to help your web browsing.

HOW much speedup?

[Have Blue (616)]

An FTP session running over a 100Mbit LAN should see about 10MB/sec real data transfer, maxing out the line and accounting for overhead. They're claiming that their gadgets could move a file between each other at 150 megabytes per second over the same cable?

As the saying goes, this requires some very extraordinary evidence. Or there are a lot of missing qualifiers like "over a specific worst-case line that TCP doesn't come close to theoretical maximum performance on".

FastTCP == 4 LoCs per hour

[maharg (182366)]

Yes, you read that right - 4 Libraries of Congress per hour !!!!

See http://www.fastsoft.com/research.html [fastsoft.com]

So where's the SlowTCP?

[bhmit1 (2270)]

If FastTCP is great for speeding things up over high latency links, what is there for slowing down connections? Particularly when you only want to take the remaining bandwidth and not impact users. I've seen various products that do this, but they never describe how it's done. Is it sufficient to slow down the connection when you see latency increase, or are there better algorithms?

Re:

[Andy Dodd (701)]

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 envir

impossible to know if real from site

[sentientbrendan (316150)]

It's true that early implementations of TCP were very naive. Over time this has been fixed, but there are still a number of problems remaining, especially to do with packet loss on WIFI networks (which it sounds like this may address).

The primary problem with WIFI networks is that they naturally have a lot more packet loss than normal links. On other links, a lot of packet loss tends to indicate packet congestion, so TCP likes to decrease throughput to try to solve it. Under WIFI, that's of course unnecessary and won't solve the underlying problem.

The article is missing some important technical details and there's a little too much marketing speak, but it does clearly sound like an improved TCP implementation, and probably some kind of traffic shaping hardware on one end (so that they don't have to change the networking stack on linux and windows, patch all their machines, etc).

There were a couple of other posters that suggested that such a thing wouldn't work. One guy even suggested that it would require different routers end to end! This is of course nonsense.

1. TCP != IP. Routers don't have to know anything about TCP to work (although they generally do for NAT, ACL, and traffic shaping purposes).
2. TCP implementations have been changed a number of times in the past. Changing the implementation is not the same as changing the protocol. Nothing else on the network cares what TCP implementation you are using as long as you speak the same protocol.

Congestion Control

[pc486 (86611)]

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.

XMODEM

[BinBoy (164798)]

This could be the XMODEM killer.

Re:

[Idbar (1034346)]

They should, in fact, start supporting ECN instead of changing TCP. Implementing ECN altogether with a well tuned AQM can reduce packet losses and difference packet losses due to congestion from those due to medium (now more important with so many wireless networks). Then, they can start looking for TCP versions that can react to congestion in a different way to the way they react to packet losses.

But that's just my thought.

The more things change...

[ta bu shi da yu (687699)]

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

Re:

[aliquis (678370)]

It was the speed of TCP which would improve, not only FTP, I guess, so therefor whatever else uses TCP should get faster aswell, shouldn't it?

Those who fail to understand TCP..

[Junta (36770)]

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

TCP is underestimated...

[Junta (36770)]

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 hig