Fast TCP uses the same packet sizes as regular TCP, and so will work with the current internet infrastructure. Instead of waiting for the acknowledgment of the receipt of each packet before sending the next, it instead uses software and hardware on the sending computer to continually measure the time it takes for sent packets to arrive, and how long acknowledgements take to come back. The Fast TCP software uses this warning of likely packet losses to predict the highest data rate the connection can support without losing data.
Caltech is already in talks with Microsoft and Disney about using Fast TCP for video on demand.
On the service this sounds like a great idea. But one thing got me at the end, when it said Caltech was in talks with Microsoft and Disney on use of the technology.
Someone correct me if I’m wrong, but isn’t the current TCP-IP implementation basically free-of-charge? That is, it’s a public standard, which anyone can write code or build equipment for?
It seems that Caltech is proposing to keep this information proprietary, which may hinder its adoption. The aim seems to be strictly high-end downloads such as movies.
And when I see Microsoft and Disney in the same sentence, I think of proprietary software/hardware owned by these two mega-corps licensing the Caltech technology.
I understand the profit motive behind innovation, but isn’t Caltech a public university? And shouldn’t basic research such as this enter the public domain?
I don’t want to see this become some kind of money-making scheme. If it works, they should give it to the world because the original founders of the net did the same thing and they are just building off of their genius. BTW, here’s the RFC for TCP from 1981.
is not a public university. It’s private.
I don’t care what tricks you pull in the protocol, you could just spew the bits out without any error checking or anything, but over a dialup, it’s still going to take hours to transfer a movie. Even over a 100Mbps Fast Ethernet link running full out with no protocol overhead, will take almost 7 minutes to transfer a 4GB DVD movie. So this "download a movie in 5 seconds" is pure BS. Probably what they’re really talking about is over gigabit+ connections, where there actually is significant delay due to protocol overhead of that sort, but that has no bearing on the Last Mile problem.
They aren’t solving the protocol overhead problem (since there isn’t one), or the bandwidth problem (if your connection doesn’t have enough bandwidth, just buy a faster one), but rather they are solving the problem of TCP/IP requiring confirmations for every packet, which means for each piece of data sent from Point A to Point B, it’s necessary for another piece of data to be sent back from Point B to Point A. This causes much bandwidth to be wasted. Currently there are various buffering and windowing techniques in use that allow X-number-of-packets to be sent before waiting for a confirmation to come back. However, you end up with what is known as BDP, or Bandwidth Delay Product, which involves both the bandwidth and the round-trip time.
Traditional TCP/IP works terribly with faster connections over distances. For example, with a gigabit coast-to-coast connection, the official TCP/IP standard 64KB buffer gives you a maximum of 8.75MB/second of bandwidth because of the BDP problem (see the link above, to BDP, which shows the math for this). That’s a bandwidth loss of 14 times because of deficiencies in the TCP protocol. With traditional TCP/IP, the main thing you can do is increase the size of your buffer, if you have Large Windows (RFC1323) enabled. That helps some, but it doesn’t solve the problem, and on systems with many active connections, the need for larger buffers for each open socket can cause memory problems. RFC2018 gives some additional help by selectively acknowledging packets. Neither of these are generally turned on by default in any of today’s operating systems, and even with them enabled, there are still performance problems.
So this is where Fast TCP comes in, and this is the problem it solves. The packets can be automagically sent at the line speed, rather than at an artifical speed determined by the BDP.