Slashdot Mirror
Fast TCP To Increase Speed Of File Transfers?
Wrighter writes "There's a new story at Yahoo about a new version of TCP called Fast TCP that might help increase the speed of file transfers. Sounds like it basically estimates the maximum efficient speed of your network, and then goes for it, dumping a lot of time-consuming error checking." There's also an article at the New Scientist with some additional information.
Let's see. Transmission without error-checking is called UDP, isn't it?
You people are giving me a headache. There is no mention about the removal of error checking. Actually, the article is lite on any technical details, but you can divine what they are doing well enough. Basically, it seems they keep tweaking mtu rwin, ect until they get the best connection they can.
This isn't revolutionary so much as evolutionary.
Mod me down with all of your hatred and your journey towards the dark side will be complete!
"When the researchers tested 10 Fast TCP systems together it boosted the speed to more than 6,000 times the capacity of the ordinary broadband links.
6,000 times? The tests done in labs are usually stripped-down and the results overstated just for statistical pleasure. In the real world, however, such figures are rarely achieved.
Measuring the round-trip time for packets and using this to information to predict the bandwidth delay product is nothing new. This is essentially one of the effects achieved with existing TCP congestion control algorithms such as TCP Tahoe, TCP Vegas and TCP Reno. The article is light on details and doesn't lead me to believe that they've done anything signicantly different from these three. Furthermore, if it *is* doing something different, how can it still obey the existing congestion control algorithms without thrashing? After all, we can all boost the speed of our TCP connections by simply turning off congestion control, as long as nobody else does it either. ;) [UDP's lack of congestion control is precisely why a few streaming video users can clog up an entire pipe for themselves, screwing everyone else who's using it.]
It's called congestion collapse and the condition is described by RFC 896 by John Nagle.
Just firing packets into the network willy-nilly is very bad; it's the "tragedy of the commons" all over again...
Actually the mention of removing error checking is in the /. article summary.
The problem is people are just reading the summary and assuming that it is actually correct and accurate.
Good points otherwise...
First of all, the New Scientist article doesn't mention anything about TCP sliding windows or congestion control.
The whole "driving a car while looking 10 meters ahead" analogy ignores a lot of the work TCP does to keep things moving fast. The "trasnmists, waits, then sends the next" packet paragraph is almost deliberately misleading.
It tosses about a "6000 times faster" statistic without explaining 6000 times faster than what. Is my dad's 28.8 modem going to suddenly be getting throughput of 172Mbps? Of course not, but what difference is it going to make to him? I think maybe none at all, and FastTCP is only for very large network hauls, but the article has claims about me downloading a movie in 5 seconds.
My DSL line is 768kbps; I get downloads of large files through it of around 85kBps, which is a data throughput rate of 680kbps. That means that all the layers of the OSI burrito, including resends, checksums, and routining information, add up to about 12% overhead. Not the best, but not that bad, either. How much improvement is FastTCP going to get me?
The numbers for their practical test of Fast TCP connected two computers that got 925Mbps, and the "ordinary" TCP got just 266Mbps. Even that's pretty unbelievable to me; I find it hard to believe that TCP was running at about 25% efficiency.
Extraordinary claims demand extraordinary evidence. Like I said before, without further technical details, this doesn't actually sound all that different than the claims of Pixelon, which also had an eye towards video on demand.
Maybe they've got something; someone linked to the actual caltech article, which I haven't had a chance to read in detail (and wasn't linked to at the time I started my post). Caltech certainly is a cool place, so there is probably something interesting going on. But the New Scientist article is a fluff piece, pure and simple, and if calliing shennanigans on it makes me a troll, so be it.
The last sentence of both news articles suggests that this broadband-optimized TCP system could be used by corporations like Disney to provide video-on-demand. (If they're talking to Microsoft, on the other hand, the result will just be a modification to the TCP/IP stack in Windows(r), which doesn't care at all what kind of data it's transmitting)
That's just wrong, at least according to the ways media companies have traditionally desired their materials to be broadcast over the internet. They typically use streaming protocols, which not only gives the user one-click startup, but also makes it non-trivial to keep a local copy of the file (enhancing the corporation's feeling of control).
However, a well-designed streaming protocol won't use TCP at all. TCP hides many characteristics of the network from the application software, and to stream properly it needs to know as much as possible. One example of why TCP is bad for streaming: in streaming, you try to keep advancing time at a constant rate. Once 156 seconds of playing have elapsed, you want to be showing video from exactly 156 seconds into the source file. If at 155 seconds some packets were dropped, you should just skip over them and continue onward. TCP, however, will always try to retransmit any lost packets, even if that means they'll arrive too late to do any good. TCP has no knowledge that packets may expire after a fixed time, but a custom-built UDP protocol can be aware of that constraint.
(Here's a reference on preferring UDP in video streaming)
On the other hand, maybe a corporation will realize that properly controlled non-streaming playback can provide a better end-user experience (guaranteeing, for example, that once playing starts, network failures will never interrupt it). In that case, they might either try to push Microsoft to integrate this faster TCP/IP into Windows(r), or more interestingly, implement it themselves in customized player software.
It's possible to implement a protocol equivalent to TCP on top of UDP, with only a tiny constant amount of overhead. So a programmer for realplayer, quicktime, or mplayer might be able to add the techniques from this research to his own code, even without support in the operating system.
The fact that the CalTech group got a lot of improvement from their implementation is good real-world evidence that your analysis is probably off, since they don't halve their TX rate and they achieved significantly better throughput.
What I'd like to know is where they did this real-world test. On a connection between two universities on Internet2 with wide fiber links, I can understand that they see a considerable perfomance gain. However, I'd also like to see tests done through consumer grade DSL or cable connections where the ISP typically use deep buffers.
If J.K.R wrote Windows: Puteulanus fenestra mortalis!