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

No Way

[hardburn]

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

HOW much speedup?

[Have Blue]

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

Re:Ok.

[aliquis]

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?

Re:Nonsense

[bockelboy]

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.

impossible to know if real from site

[sentientbrendan]

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.

Re:Nonsense

[Ant P.]

I don't think you're the target market for this piece of hardware.

Re:Nonsense

[Anonymous Coward]

I dunno, at a previous company I built a FTP gizmo based on Windows 2k which could saturate a 1000 mile long OC3 line. That's 1.4 TBytes a day.

To transfer 20 TB/day, you need something like 1.8 Gbps sustained, not my measly 155 MBps, but that's only (only!) an order of magnitude better. TCP has shown itself quite comfortable scaling up from 300 baud modems to GigE links (6+ orders) so what's one more among friends? This is not to say TCP can't be improved: I've always thought using dropped packets to measure congestion was a but hokey, but it seems to work fine. If the fine researchers at CalTech think they can do better by measuring RTT, that sounds just great.

Re:No Way

[644bd346996]

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.