A number of articles this morning, including this one from BBC News talk about Fast TCP.

Unfortunately, the examples that each of them give, about TCP breaking transmissions up into 1500-byte morsels, sending one packet and waiting for an acknowledgment before sending the second one are patently untrue, so what is Fast TCP and how can it really help?

This (rather ugly) page from Stanford University's Internet End-to-end Performance Monitoring (IEPM) group (at SLAC, the Stanford Linear ACcelerator) has some real-world performance comparisons between using multiple TCP streams and using Fast TCP, so that gets us some more info, at least showing the benefits of the protocol. But, it still leaves us wondering what it is.

A paper from CalTech provides a bit more insight, going into the use of very-large windows (14,000 packets+ at 1500bytes) and the use of aggressive algorithms at the transmit side to send more data in anticipation of the window opening up (basically, sending data outside of the window in expectation that by the time the new data arrives, the earlier data will have been acknowledged and, although the acknowledgments had not yet been received, they will arrive in time to re-fill the link.

This approach is particularly interesting, as it doesn't really require the use of a modified TCP stack on the receiving end, just on the transmitting end. It does, however, require some sophisticated algorithms for estimating loss and recovery, so that you don't bounce too many out-of-window packets at the receiving host when a packet is missed.

Crafty.