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.
Thats what TCP does, just in a passive fashion. The sender queues all sent packets for resend, (on a delay) and packets are deleted from the queue when an acknowledgement for a range of packets is recived from the remote computer.
If you're curious: RFC 793
Looking at the information on their web page at caltech, the FAST network project is working with alternate TCP window sizing schemes.
Namely, instead of reducing window size in the case of packet loss, window size is changed based on round trip latency. The problem being that reducing the window size in response to loss works well on most networks, but has a serious problem when dealing with very high-bandwidth links.
In such a case, the conventional TCP windowing will shrink greatly in response to even one or two lost packets, which when you are sending a LOT of data, will occur.
The real work (and it seems to be somewhat covered in their web pages) is how to use latency for congestion detection/control, but I haven't read it in enough detail to quite understand this, NOR how this scheme will interact with conventional TCP streams.
Test your net with Netalyzr
This protocol figures out ahead of time if it needs to slow down so its always getting acks back instead of waiting for timeouts. Also it avoids the binary backoff time that happens with timeouts.
So in response to many of the previous posts it loses none of the robustness of TCP. In the worst case its as slow as TCP and in the best case it should be equally as fast as TCP. In the average case, however, it shows a huge performance increase. Most of the time on the network is the average case so this is a good thing.
"You can now flame me, I am full of love,"
I can only assume that the 'description' of how normal TCP works has been 'simplified to the point of being wrong' by reporters, because it is totally wrong. The description of 'why fastTCP is better' then proceeds to describe 'normal tcp as it actually works.'
Any then they totally confuse the issue by mentioning that you can use multiple high speed links in parallel to get higher overall bandwidth. Boy am I impressed.
455fe10422ca29c4933f95052b792ab2
Actually UDP error checking is optional. If the checksum field is zero, the packet integrity is not validated.
Tom
What you're talking about is a NACK (negative acknowledgement). Basically, if I miss a packet, I'll send a NACK. Some protocols use them, but you can't use NACKs exclusively.
If the recipient never NACKed a packet, the sender wouldn't know if the all the packets were getting through or if none of the NACKs were getting through.
http://yetanotherpoliticalrant.blogspot.com
Yes indeed. 6000 times faster is possible, but 6000 times faster than what? 6000 times faster than broadband? Maybe if you're downloading a video with one very slow hop in between, and then you all implemented this it could be 6000 times faster. But there's no way it could be 6000 times faster always, or even on average. Go download aol instant messenger and look at the speed. I just did it and got 308 KB/sec, and I've seen as high as 440 from AOL's servers. You mean I could download that same file from them at 1,848,000 KB/sec or 2,640,000 KB/sec with this protocol? (Please just kindly correct my converson if I'm wrong, but that would be about 1.8 and 2.6 gigs a second would it not?) Forget about the protocol, that's rediculous for most hardware. Wide ultra2 scsi only transfers 80 megabytes per sec. How would I download. Can today's ram and motherboards even work with gigs a second?
Is this really as rediculous as it seems to me? I always get confused by the big B/little B byte/bit distinction.
Yep, definitely not hundreds of pages of technical specifications available anywhere.
The speed, er... rather the window size is changed according to a rigid design, and ideas like this in the past have failed because once everyone is doing them, they stability of the network decreases. Mind you this is distinctly different that "removing error checking" because it is basically taking two steps forward instead of one step at a time. If you leap ahead two steps, and fail you simply step back one (which is still one step forward). The packets are still resent on the TCP leaving the application to not worry about data quality. Looking at packet captures of ftp traffic show that ftp is an aggressive consumer of bandwidth, and that ramping up or down near the beginning or end of the TCP session is were the greatest amount of *inefficiency* is found. So the idea is to make tcp more aggressive near the ramp-up/down stages of the connection. The idea also being to remove some of the agonizingly redundant error checking in favor of self-throttling optimistic educated guessing. Fast TCP simply wants to do the dirty work ahead of time instead of gradually discovering the safe speed limit. Fast TCP will bump into glass bandwith ceiling at mach 10, instead of 10 Mph, quicly recovering by resending the big chucks at a fraction of the window size previously sent. So it could also be described as willig to find the threashold quickly in echange for knowing the boundrys instead of wasting precious time ramping up. Traditional TCP hates data loss to the point that is "drives slow in a parking lot" attempting to never have a colision, whne the protocal itself is well designed to recover from such an event already.
It isn't a lie if you belive it.
I see this as a way to transmit corrupted files, not a way to speed up the internet experiance as a whole.
Without trying to be mean, you see it that way because you don't understand what's going on (mostly because the post was misleading). Fast TCP packets will still have a checksum and everything, so you're not going to get corrupted files. The change here is that normal TCP halves its "window size", or the amount of info that's out on the network at once without receiving an acknowledgement of receipt, with each error. This means that if there's one minor slowdown when 10 packets are currently out from your computer to the recipient (you've put out 10 packets without getting an ACK back yet), then your computer will reduce its window size and only allow 5 packets to be out at a time, effectively halving the transmission rate. Since TCP continually tries to get faster, it will always hit a bottleneck, resulting in your connection vacillating between optimal speed and half of that (approximately, I guess it might be worse than this on high-speed networks based on what I've read here).
In Fast TCP, they do this "congestion control" in a different way. Rather than halving the connection speed with every slowdown to ensure stability, they send as much data as possible as long as the network seems clear on the recipient's end (I think they estimate this with round-trip time of some sort).
So the "error checking" being changed by Fast TCP is NOT bit checking -- it's transmission rate checking. You'll still always get your files intact.
Yeah, I was right.. there's a link to caltech further down which actually describes what they're talking about. Good to know that nobody but the reporters really think we're all still using xmodem/kermit like one-packet-and-wait protocols
455fe10422ca29c4933f95052b792ab2
Second, it's intended for use for single big flows on gigabit networks with long latency. You have to be pumping a few hundred megabits per second on a single TCP connection over a link with 100ms latency before it really pays off. It won't do a thing for your DSL connection. It won't do a thing for your LAN. It won't do a thing for a site with a thousand TCP connections on a gigabit pipe.
Third, unlike some previously hokey attempts to modify TCP, this one has what looks, at first glance, like sound theory behind it. There's a stability criterion for window size adjustment. That's a major step forward.
(I first addressed these issues in RFC 896 and RFC 970, back in 1984-1985. Those are the RFCs that first addressed how a TCP should behave so as not to overload the network, and what to do if it misbehaves. So I know something about this.)
And I should clarify my first post as well by explaining what a "transmission error" is that would cause the window size to halve. From the article above: Basically, what I mean by a "transmission error" is a timeout -- the sender sends a packet and never gets an ACK for it. TCP works on the premise that packets are mainly dropped when congestion is high enough for routers to drop packets because of maxed buffers. Thus it makes sense to reduce transmission rate when no ACK is received to adjust to the capacity of the network.
It sounds like they are working on a replacement for the Nagle algorithm. Nagle works well on clean connections, even if badly tuned slow-start gets annoying when you have gigabit connection and it still takes a minute to ramp up to full speed on an ISO download. Where "fast tcp" would really help is on a dirty connection. I had to connect to a supercomputer a few years ago over a 100Mbps link that corrupted or lost 30% of all packets and I had to use my own streaming on top of UDP to avoid getting hammered by shrinking windows (I still needed congestion control.) On this type of connection I'd expect their "fast tcp" might give a 10x speedup. On a normal non-noisy and relatively slow DSL connection, like I have at home, I'd be surprised by a 10% speedup.
In other words the story is all wrong, but what they are doing is actually worthwhile. You sometimes have noisy networks, especially when they are wireless or in an industrial environment. The big long haul telecoms lines are better off doing error correction on line, but in the last mile you never really know the noise characteristics so this should be handled better on the TCP level. I would probably do something like FEC with the number of recoverable errors per packet and per lost packet per logical block, tuned to the error characteristics of the network. Then call it TCP2 and release an RFC and some BSD licensed source code.. (I thought of doing this as part of building an ISP friendly P2P protocol but decided I didn't have the time..) Their solution has the advantage that it works just great with regular old TCP implementations.
At the risk that you're trolling, Kermit is actually very good indeed (after 1990 or so,) assuming you set your options correctly.
The defaults are slow, but they work; that's Kermit's raison d'etre and why it's still around. But Kermit was probably also the first protocol to implement sliding windows and configurable blocksizes; Zmodem probably got that idea from Kermit. Set your options correctly, and Kermit's damn good.
The age of the BBS is over (I ran one for about 12 years) but I'm pretty sure I'll use Kermit again before I have cause to use Zmodem again.
--
I don't want to rule the world... I just want to be in charge of mayonnaise.
I suggest you RTFPDF namely this one.
:-
Which says nothing about hardware (and none of the others I read mentioned any change to hardware)
Also a little reading and you will discover this is just a stop gap measure untill ECN is fully deployed.
And yet more reading will produce this little gem at the bottom
With 9,000-byte MTU, Linux, FAST and Scalable TCP all sustained more than 2.53Gbps on a single flow between Sunnyvale and Geneva, apparently limited by the transatlantic link. HSTCP sustained 1.8Gbps in that experiment. We emphasize that these experiments are preliminary and not yet conclusive
Kermit with sliding windows was/is known as SuperKermit. zmodem leapfrogged SuperKermit (pun intended) speedwise by using a more efficient encoding and larger blocksizes. And, it was less processor and memory intensive than Kermit. But Kermit was more robust.
I guess it's just not easy being green.
Normally, when you're sending stuff from point A to point B, there is a lot of buffering on the way. At the point where you lose a packet, you've overflown a buffer somewhere. Halving your throughput at that point is probably a good idea - you may be backing off your data transmission a lot right now, but there should be plenty of data sitting in buffers out there that needs to be cleared anyway.
If you only back off a little bit, what happens is you just go overrun that same buffer again, and just send out a lot of data on your end that's just getting dumped halfway out.
Think of it like dumping bags of sugar into a big funnel. You start by dumping in a quarter bag per second, then a half bag per second, then 3/4ths bag per second, then a bag a second, then 1.25 bags per second, then 1.5 bags per second...
At which point you notice that the funnel is full and sugar is overflowing it. At this point, does it make more sense to go back to dumping 1.25 bags per second, or 3/4 bags per second? (Hint: It's 3/4ths.)
By the time you've lost a packet from overflowing a buffer, you definitely want to back off more than a little. The rate you're filling the buffers is likely at least an order of magnitude higher than the rate you're emptying it, so it only makes sense to back off by at least an order of magnitude.
paintball
I stand by my claim that the New Scientist article sounds like snake oil. It's a misleading article, pure and simple.
But, now that I've read some of the documents from the Caltech site, and I think I understand the claims, the research is fairly interesting, at least in the world of "ultrascale" networking. Of course, I'm just an unfrozen caveman engineer, and that world confuses and frightens me, so my understanding might be slightly off. Here goes anyways.
As I understand it, the authors are saying that current TCP congestion avoidance algorithms break down on very high speed, long-haul networks. They mention looking forward to 100Gbps and higher speeds for "ultrascale" supercomputing. They have papers analyzing TCP Vegas (which was designed in 1994) and show that for the networks they're looking at, Vegas "does not scale to this regime". Specifically, they examine throughput stability of Vegas, and show that with these ultrascale networks, performance can end up bouncing between the two states of "balls-to-the-wall" fast and molasses slow. (They do not actually use the phrase "ball-to-the-wall"; that's my addition.) Network performance doesn't reach equilibrium, and your average throughput is quite ugly. In this context, the "cars starting and stopping" analogy starts to make sense.
This is a fairly different "regime" than I'm used to; then again, I'm an unfrozen caveman engineer, and the fastest neworks I've dealth with are 10Gbps LANs, and not high speed WANs. It appears that network performance on such networks can be surprisingly bad, at least, it's surprising to me. (And heck, there's a world of conditions under which Vegas is a great TCP congestion control algorithm, and the network delivers fair bandwidth to everyone. They even link to plenty of papers which analyze, simulate, and measure conditions where current algorithms work just fine.)
They're really looking forward to where the network finally starts to reach pathological extremes, and this all breaks down, which is different than conditions I (and most readers of the New Scientist article) would have seen.
Their first solution, by the way, is a slightly modified algorithm called "stabilized Vegas". They prove that this algorithm avoids the oscilating behavior, and thus avoids the low throughput situation that results. Neat.
Let me summarize my summary: original article bad, sounds like a scam. Actual research interesting, but applies to network speeds and conditions that are forward-looking, and probably don't directly apply to Mr. Bob Homeuser for quite a while. Fire bad.
It comes with Solaris right now. You can also get it for Linux. Why?
It's useful when the ssh client has it built in because you get pretty much the same speed and the ability to download between clients.
By the way, I know about two zmodem-enabled ssh clients:
1) SecureCRT - nonfree/Windows only.
2) Zssh - open-source, cross-platform.
The actual applications which initiate the transfer are called "rz" and "sz."
Mod me down and I will become more powerful than you can possibly imagine!
As I see it (hard to say because the article wasn't exactly technical), here is how it's going to work:
That's wrong. You were possibly misled by a bad article. Your diagram of "Slow TCP" isn't describing TCP at all, but a more primitive protocol that can be called "Stop and Wait". Stop-and-Wait provides some of the same advantages of TCP (reliability and consistency), but obviously takes a painfully long time to transmit a file, so it's little used in real life.
The idea that you can send many data packets before getting an ACK is already part of normal TCP. It's called the "sending window", and it measures the number of packets that can be sent before waiting for an ACK. The sending window is basically an estimate of the bandwidth of the link, which TCP maintains as it runs. The estimate starts out low, and then is continually increased as the transmission goes on. As soon as ACKs fail to arrive, the assumption is that the bandwidth was exceeded, and the estimate is cut in half. It's a linear-increase, exponential falloff procedure- which is meant to prevent from impairing the TCP performance of other users (you increase your transmission speed slowly, but decrease it quickly if there's an overload). The lineary increase of the window size is called "slow start".
Apparently, this research uses a different technique to obtain the starting estimate of the bandwidth available. Instead of sequentially increasing the window size up to gigabit levels as the connection goes, they start out with a large estimate, because they already know the link is fast.
This is stretching my certainty (I'm recalling all of this from a sophomore year CS networks class and I've been overwhelmed by booze in my graduating week), but here's a stab at this...
I don't think that having a long RTT (round-trip time) will have a huge effect on transmission rate in the standard TCP case. Internet traffic, if I remember correctly, is bursty (cite), meaning that a typical transmission looks like:
SEND 32 PACKETS
RECEIVE 32 ACKS
SEND 36 PACKETS
RECEIVE 36 ACKS
SEND 40 PACKETS
RECEIVE 38 ACKS
(oops! Sent 2 more than I could! Halve TX window!)
SEND 20 PACKETS
RECEIVE 20 ACKS
etc. In this case it's easy to see why having a long RTT doesn't slow things down particularly, since there can be a big gap between the SEND and RECEIVE and nothing changes.
In the case of non-bursty traffic, I don't think large RTT causes a big problem for normal TCP either. This is because even with a large RTT (if it takes 400 ms to go from sender to host, for example) ACKS will still be streaming in at a constant, if slower, rate, allowing for more packets to be sent out (this is more subtle to explain, so you might want to google more for a better explanation).
I think the reason you misunderstand this is because the New Scientist article makes it sound like you send a packet, then receive an ACK, then send one, etc. This is not the case -- you send lots of packets together...this is the principle behind the "window", that you can send out more than one packet at a time without receiving an ACK because you've been successful at that so far.
FYI, I looked up MCI's traffic times and found that transatlantic latency is roughly 80ms compared to 45ms for within-US traffic (cite). This is non-trivial, but also not huge.
If anybody disagrees with this assessment, please feel free to correct, since as I said, I'm not 100% sure that increased RTT doesn't mean lower window size.
Also, from my reading a lot of the gain was simply in the fact that halving a throughput rate of 800K/sec means you're dropping to 400K/sec when realistically you should probably only be dropping a little bit. According to NS, they improved by more than two-fold, but that's probably just because normal TCP doesn't often get to the actual max of the network, it may burp a lot on the way up and dip more than halfway than its reasonable max.
This is true, but when the TCP congestion window is full (or the Receiver window), TCP has to wait for acks. So the original is not totally untrue either.
Both Ethernet (the most common linksystem to run IP on) and TCP has abilities to throttle. TCP does this by simply waiting some time between retransmits if it senses a lot of package loss (either by never receiving ACKs or receiving multiple ACKs with the same number). It does so by shrinking the Congestion Window, and thus makes sure it has to wait for ACKs before transmitting the next package sometimes.
Remember that IP itself does not make any guarantees that packages will reach the receiver in-order or even at all. It is TCP that provides the concept of reliable data transfer by doing retransmits.
The article is uninformed however, and this mechanism for congestion control is a necessary and important part of TCP. Leaving it out so that you can squeeze some more juice out of the system will only lead to hurt in the long run.
The mention of "156 seconds" was an oversimplified example of the kind of problem. It does happen in real streaming applications, however, especially if playing from a live source where latency constraints don't permit lengthy buffers (most important in bidirectional VoIP apps)
.
Of course a streaming protocol uses a buffer. That's one reason why you don't want to run it over TCP. TCP provides its own buffer, which would be redundant with the one the higher-level protocol is also creating. Optimally, one fully-informed piece of software can manage all buffers.
Streaming music over TCP (even HTTP) is fine, because the bandwidth needs are so low that suboptimal solutions work. Streaming video is different- not only is the total bandwidth more than 10x higher, but you've got two separate streams of data whose buffer sizes need to be correlated.
Essentially, if the network is stressed enough so that framedrops (underflows of the application-level buffer) ever happen, then TCP will waste time retransmitting old data, while a hand-rolled UDP solution will recover quicker . Today's popular audio-only streaming doesn't usually push enough data to cause framedrop events
You can experimentally check that UDP is better for streaming video with applications like RealPlayer. Watch some videos with it. Then adjust your firewall to block it's UDP ports (6970+) and try again (or use the HTTP setting from inside realplayer).
No, the guy at new scientist got it right... TCP uses an AIMD (additive increase multiplicative decrease) rate control algorithm. The rate at which you send is controlled by the window size at any given time. If you detect a loss, you decrease your window, dividing it's size by 2. If packets are arriving ok, you make small increments to your window size.
This new protocol uses a different window management algorithm. It uses the acks as probes, (I guess they measure delays) and if 'the coast is clear', it maxes it's transmission speed
I do wonder about FAST TCP congestion control capabilities, thugh... As for the poster who taled about slow start, sorry pal, but slow start is just the name...At that state, the transmission rate is increased quite fast, actually
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
TCP does not provide its own underflow buffer. I'm sure modern implementations provide an overflow buffer to make sure it doesn't overwhelm the physical transport layer, but it is not the kind of buffer an application needs to ensure the seamless delivery of streaming content. Does any implementation of TCP allow for the aggregation of an arbitrary amount of data before handing it off to the application? No. That would be counter productive.
Also, RTSP is a protocol-independent stream control mechanism. The RFC clearly states that all application data is transmitted out-of-band in another protocol. It is only a "transmission control" protocol (not to be confused with TCP, of course) and allows for the transport-independent control of data streaming to and from different sources on the net.
In other words, it's not used to make sure the content itself gets from one place to another reliably (or unreliably). In fact, the RFC also provides support to specify a lower-transport protocol for (out-of-band) streams, either UDP or TCP. This would presumably would allow for both reliable and unreliable transmission of data, depending on your specific application.
So in conclusion, reinventing TCP with UDP is a dumb idea and is not what RTSP aims to do. It probably plays a vital role in controlling the behavior of things such as VoIP phones. In such applications, when latency is negligible, buffers are not practical, and a reliable transport mechanism is assumed, then no, a buffer is not necessary or practical, but these assumptions do not apply to the internet-at-large in the least. If you want reliable data on the internet, you use TCP. Period.
The dangers of knowledge trigger emotional distress in human beings.
You don't want to go UDP because a lot of nodes you might have to traverse across the internet will drop UDP packets while queueing TCP packets. The TCP overhead winds up being smaller than the necessary redundancy you need to add to UDP. You really only want to use UDP in situations where you can actually afford lost information to stay lost, at least until better routers come along and are widely installed.
"Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
Actually, though, he was correct since in the latest forms of TCP found in kernels today (just check out the Linux source code...), ACKs are already used as probes to determine congestion *and* RTT for throughput purposes. With advancements like TCP Reno, and newer, rarely does TCP ever go into a full timeout, or even hit a point where multiplicative decrease is actually needed, more often just additive decrease is required to maintain efficient congestion control.
But you are correct, slow start is anything but. It certainly is much better than just flooding the network right off the bat, however yes, it does have an exponential start. The major disadvantage of slow start is the fact that it starts from one segment onward, which is obviously worse than just halving the window.
I refuse to have a battle of wits with an unarmed person.
I believe this is HSTCP.
For more info, you can also take a look at:
Web100 and Net100.
It basically amounts to improving the AIMD algorithm and changing the way slow start works as well. Also, whoever said it before that this will not help your DSL connection is correct. It is meant to help high speed long RTT paths. And it does so -- quite well.
It's called RTP (Real Time Protocol) which contains timestamps for determining when each packet is supposed to arrive. Feedback is sent back to the transmitters by a related protocol called RTCP (Real Time Control Protocol) which let's the sender know about "jitter" (variation in packet arrival times), lost packets, and other problems. Read RFC 1889 for more info. (RFCs available here.)
Errm, no. In currently deployed versions of TCP, routers *never* send direct feedback. Implicit feedback is obtained (at the sender) by sensing end-to-end packet loss or delay.
This is done in TCP Vegas, which was first proposed in 1994 and I think is fairly common now.
TCP Vegas uses queueing delay as its congestion control measure. The delay is implicitly fed back to the source via the end-to-end delay experienced.
that all the other streams are going to back-off during collisions. TCP normally backs off when a packet is lost because it assumes that the router buffer is full. It seems like if *everyone* used FastTCP, and no one backed off, it would simply DOS routers all over the Internet. Basically, a router buffer fills up, but everyone keeps sending at an astronomical rate, leading to 100% packet loss. Eventually it would back down far enough that the buffer would open up again, but only briefly, and the process would repeat. TCP was designed to be fair, not a bully algorithm. This thing goes in and violates that fairness principle, by being a bully while everyone else plays nicely. TCP works for the benefit of everyone, by having a universal understanding that unless everyone plays nicely, everyone loses. Hopefully this won't catch on...
Been there, done that.