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?
Why not just number all packets between two hosts and if the recipient doesn't recieve a packet it requests that particular packet to be resent? I see problems with man in the middle attacks but is there any other reason?
just wondering
This is interesting, but is it realiable? I'd rather take rsync any day even if it happens to be slower, as long as it's sturdier.
speed or accuracy..either one...
I'm sorry, but without further technical details, this sounds like the sort of technical mumbo-jumbo that snake-oil salesmen were peddling back in the dot-com era.
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...
without further technical details, this sounds like the sort of technical mumbo-jumbo that snake-oil salesmen were peddling back in the dot-com era.
The New Scientist makes it quite clear on how the Fast TCP is done, if you know anything about how TCP works (and how the window size halves in the event of packet losses)
shame on a relatively low-ID user making such trollish comments...
TFTP sucks in the presence of packet loss. Its mechaism to deal with lossy networks is, umm, "trivial" :) The server sends one packet at a time, and waits for an ack after each. If a data packet or ack packet is dropped the server or client retries after something like 5 seconds (configurable, but in seconds). TCP retries faster, and keeps multiple packets in the air at one time.
- AB
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 TCP sliding window protocol does this. When you request a page, some data is sent to you. You send an ACK. the server then sends that same ammount of data, plus some more. Then you send an ACK. This continues until you stop sending ACKs. Then the server knows that it needs to back off a bit.
I'm pretty sure this is a standard in TCP/IP.
I'd rather you do it wrong, than for me to have to do it at all.
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!
I have an idead! Fast TCP transfers with no error checking... And we'll call it UDP.
Karma: The shiznight, mostly because I am the Drizzle.
I call bullshit, or at least very unclear wording. What are these "connection buffers at your ISP"? ISPs don't provide connection buffers, because that's not how TCP works. Routers keep no state for TCP connections; it is only the two endpoints that keep state. All that routers do is forward (and buffer) individual packets, and they don't care what connection each packet is part of.
Furthermore, about all that buffering packets can do is increase your latency. And, if you are doing proper congestion avoidance, then most of the time latency will be increased only a small amount and in a fairly predictable manner. And by the way, not letting high latency prevent you from having high bandwidth is a solved problem for TCP. At least, it is if you are using a decent TCP stack that can support big windows.
By the way, I'm not even sure I believe that the Fast TCP test mentioned in the article is a valid test. The article makes it sound like they took empty pipes and ran only one or maybe only ten Fast TCP connections over them at the same time. In reality, a core Internet router will run thousands of TCP connections at once. The inefficiency of TCP when it comes to congestion issues is that it backs off exponentially when it detects congestion, thus wasting theoretical bandwidth if you have a small number of connections on a single pipe. But if you have a really large number of connections, they are all doing their exponential back-offs at random times, and those exponential back offs are a much smaller part of the pipe's total bandwidth, so I would expect somewhat less bandwidth waste. I wish they had tested in that kind of environment -- an Internet router will thousands and thousands of TCP connections of varying bandwidth. On the other hand, if Fast TCP works equally well in most cases but works better in some (a router carrying a small number of high-bandwidth connections), then it's fine by me.
This really devastates the credibility of CalTech
as an institution. It seems clear that some group
at CalTech pumped this to the media, to the point
where a categorically deceptive series of fluff
pieces entered the news stream.
Compare this to the "cold fusion" debacle in '89:
Pons and Fleischman reported valid, and eventually
reproducible results without hype, but the media
pumped it with speculation. Pons and Fleischman,
excellent, highly competent and productive stars in
their field, were essentially tainted by no fault
of their own, and run out of town on a rail.
It's galling.
-I like my women like I like my tea: green-
the challenge is to make this 'better tcp' to co-exist with other versions of tcp currently deployed on Internet, like Tahoe and NewReno.The key point is the notion of 'fairness'. The way TCP (at least the currently deployed versions) are designed is to cooperate (in a sense) as to provide the equal share of bandwidth to competing flows. That's one of the reasons why it is so difficult to introduce TCP-like protocol with radically new design. I believe one of the reasons TCP Vegas (which has a good potential) does not get deployed on a wide scale is that it is not entirely clear how the mix of Tahoe, NewReno and Vegas would perform in terms of fair share.
... I wouldn't call it a 'breakthrough' though.
however from what i've been reading on caltech site, it appears that one of the usages of this protocol would be to download very large file on dedicated pipe (like movie on demand). From movie server to the user through private connection. This makes sense. You can streamline lots of things. OPtimize protocol for a fat pipe. Whatever