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.
SmartTCP. It sounds like equipment is constantly tweaking the connection for the optimum through put.
Mod me down with all of your hatred and your journey towards the dark side will be complete!
No, UDP has error checking per packet via a checksum. What they are talking about is probably something to do with TCP "slow-start" where TCP connections speed increases slowly so as not to flood the network at first. I think the speed starts out exponentially with each packet then backing down some when packets are dropped.
Morphing Software
I remember back in my BBS days what a big deal zmodem was when it started getting used all over the place. As I recall, it changed the block size that you would receive dynamically based on line quality.
So when you sent a block of 2k and got no errors, the frame size increased to 4k...8k... etc etc... Sounds like a similar approach.
Case
P.S. That was a long time ago in a FidoNet far far away, so my terms may be off.
Isn't estimating the effective bandwidth of the link exactly what tcp window is all about?
I read the article and did not understand what do thay add that is better then the standerd tcp enhancements of selective ack and big window sizes.
clue anyone?
As of Postgres v6.2, time travel is no longer supported.
The nice thing about using TCP rather than UDP is that it has connection state so you can filter packets more cheaply, as well as doing NAT more cheaply (both in terms of processor time.) With IPv6 NAT shouldn't be much of an issue but filtering is still a big deal and getting bigger.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
The article seems kinda stupid to me, it describes a basic "stop-and-wait" protocol where only 1 packet can be in transit at a given time, and if it gets lost, it is retransmitted. I am pretty sure normal TCP has a window where it can send up to X packets at once and retransmit any particular missing one. I am sure there is room for improvement, but TCP is a fairly complex protocol already and the article seems to forget about all that.
Morphing Software
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?
Because that is exactly what happens already. The reason this system is slower than FastTCP is because it's non-predictive. It just takes a shot at the maximum speed and if it doesn't work the first time, it tries again at a slower speed until it works.
Does that mean TCP has 99.99% (humor me) overhead ?
But seriously, you can probably use large windows to send streams of packets such that a single ack is required for a bunch of them, but it's impossible to achieve 6000x more throughput just by "optimizing" the TCP protocol. Even over Internet (I'm not even talking LANs since there is obviously not that much room for improvement due to the low latency).
Looks like this this
SCTP is a reliable transport protocol operating on top of a connectionless packet network such as IP. It offers the following services to its users:
-- acknowledged error-free non-duplicated transfer of user data,
-- data fragmentation to conform to discovered path MTU size,
-- sequenced delivery of user messages within multiple streams,
with an option for order-of-arrival delivery of individual user
messages,
-- optional bundling of multiple user messages into a single SCTP
packet, and
-- network-level fault tolerance through supporting of multi-
homing at either or both ends of an association.
The design of SCTP includes appropriate congestion avoidance behavior
and resistance to flooding and masquerade attacks.
We substituted the coffee Slashdot normally drinks with "Sandoz Crystals", Lets see if they notice the difference
#1. No. UDP has error checking. The difference between UDP and TCP is that TCP is a connection-based, sequence-enforcing protocol, where UDP is basically raw connectionless datagrams that arrive in any order and you have to handle packet loss and reordering in your application.
#2. RTFA.
#3. They're not getting rid of error checking. It sounds like they're reworking the windows for ACKs in TCP to allow better streaming over high speed, but realistic (IE, slightly lossy) networks. Current TCP aggressively backs off when packet loss is detected, to prevent flooding the weak link in a network connection. It works really well for consumer network speeds, but on very high speed networks (EG, 45 Mbps), even very light packet loss will drop your speed dramatically down. TCP just wasn't meant to scale to these kinds of speeds, and some reengineering needs to be done to make it work smoothly. Many of the current extensions to TCP have made matters a lot better, but it's still going to have trouble scaling to gigabit, high latency networks, and it's best to start dealing with these issues early.
This is part of a whole bunch of TCP and networking related work at CalTech.
I hate to do this to them, but the Caltech Networking Lab site has more info.
From what I see, the improvement here is to use packet delay instead of packet loss for congestion control. They claim this has a bunch of advantages for both speed and quality.
Here is a Google cached copy of their paper from March 2003.
As near as I can tell from the popular articles, and the web page referenced in the New Scientist article, "Fast TCP" is not a new protocol, but rather better congestion control for standard TCP. I'm not a network guru by any means, so please take the comments below with a grain of salt.
Currently, TCP implementations use a standard trick to play nice with small router queues. Using precise timing would be better. I hassled Mike Karels over it about 10-15 years ago, but the consensus at the time was that the hardware wasn't up to it. Now it is. Also, modern routers have gotten clever about queue management, which screws up the trick.
The new proposal is to take advantage of modern HW to measure latencies. Existing TCP could thus be used more efficiently, by allowing larger amounts of data to be outstanding on the network without trashing routers.
It is not widely understood that in 1988 the Internet DOSed itself because of a protocol design issue, and Van Jacobsen got everybody to fix it by a consensus change to the reference implementation of TCP. These articles appear to report (badly) ongoing research into that issue.
Maybe they're measuring the round-trip delay, and then sending more data than can fit in the reciver's window, on the assumption that ACKs "should be" in flight. Maybe they also notice when an ACK is overdue, and send a duplicate packet early, rather than wait for the normal timeout or a duplicate ACK of earlier data. If they do that, then the duplicate would come 1 RTT after the original, and the reciever's window would be full of after-loss data (so it would catch up right away.) I suppose they could assume that only one packet would be lost, and send another window-full of data after that, before recieving an ACK. (If that assumption was wrong, then that data would be lost and bandwidth wasted.) ... but that's all just guessing.
I do hope that there is something to this (in spite of the fluff of these articles.) We're kindof stuck in terms of throughput with TCP right now.
The former inequality is reasonably easy to fix -- make bigger windows (and buffers). The latter is harder. 9.8 is a constant (I don't know where it comes from, but that value is often quoted, and seems to work out in my experience.) It would be great to fix MSS, but lots of hardware won't support more than 1500 bytes, and nobody benifits from this until everybody upgrades, so nobody upgrades. For fast links, RTT is mostly determined by the speed of light.How about TCP Vegas? They use RTT measurements to proactively determine congestion.
... "follow me" the wise man said, but he walked behind
data link layer technology, like Ethernet, already has error checking built into it's frames, so why is there a need for another error checking at the higher transport layer?
1f u c4n r34d th1s u r34lly n33d t0 g37 l41d
See caltech's press release on FAST for an article that actually makes sense.
Also, could someone please explain to me why boringly predictable stereotypical slashdot feedback is being modded up?
"Whoa! Faster pr0n!"
"Imagine a beowolf cluster of these!"
-Insert completely unrelated Microsoft bashing post here-
-Insert completely unrelated technobabble from some geek posting out of their ass (without reading the article first)-
News for nerds. Stuff that matters. Discussion that doesn't.
The article pointed out an interesting variant of TCP for improving transfer performance. However, the conditions they were using are the equivalent of trying to break the land speed record on a salt lake that's as smooth as a billiard-table and hard as cement.
In other words: it's not very realistic, nor appropriate for most internet usage with shitty connections. It would be like trying to use a 600mph dragster (this protocol) on a dirt trail up the side of a mountain (a 56k modem). Even at a highway speed of 80mph (with regular broadband), you don't need anything much faster than a regular vehicle - and anything specialised is liable to give you problems.
Having said that, there's no reason not to mess with your broadband connection (tweak the MTU, TCP window, etc) to see if you can eek more performance out of your existing protocols. There is an excellent broadband tweaking guide that's well worth reading and did help my Windows box. YMMV.
Totally ridiculous. That's the kind of crap you can expect from a totally clueless reporter. The sentence is ambiguous and in the end, it doesn't really say anything.
For some reason, he felt the need to mention that 10 systems were tested "together" without saying how.
It says that FastTCP can boost the speed past the "capacity" of ordinary broadband links. I don't know how you can get performance that exceeds the capacity (which I take to mean the theoretical limit). On the other hand, it isn't really clear if they even used "ordinary broadband links". For all we know, they could have been testing on a local GigE network (or on localhost!).
If he's trying to say that FastTCP gets 6,000 times the throughput of TCP, then this implies that TCP can be at most using 1/6,001 of the theoretical maximum. I'm guessing that they're advertising some corner case (or the reporter is retarded, which is probably just as likely).
FastTCP just seems like a better predictor of the delay/capacity properties of a connection. The New Scientist article says in one place that they were able to achieve a 4x increase in transmission speed between Geneva and California, which is impressive, but it's probably under strange conditions. The graph in their paper shows that FastTCP utilizes the link about twice as well as regular TCP when you get to 10Gbit links. The "reporter" must have done some serious mangling to get the number 6,000.
This quote is, IMHO, the mark of true innovation. Good researchers strive for solutions that are clear and self-evident... once they're discovered. On the other hand, cheap attempts at innovation are often convoluted messes that make you think "wow, I have no idea what that does or how it does it, but it sure is confusing so maybe it's innovative".
I guess I'd only make one change to the quote to make it match my conception of true innovation: "Wow, that's a pretty simple idea, but there's no way I would have ever thought of that."
They represent TCP totally wrong. Not only that, they describe the whole network infrastructure wrong.
:(
No wonder I have trouble explaining how the network works to my sister, or even to my mother who happens to have his masters in tech. (Albeit in mechanical engineering)
Let's see.
"The sending computer transmits a pack, waits for a signal from the recipient that acknowledges its safe arrival, and then sends the next packet"
No honey, thats why we have the buffers. So you could receive packets out of sequence and wait for the middle ones to arrive. This is why we have 32-bit seq and ack fields in the tcp header just after the src and dst ports. seq tells the packets order in the queue. Ack tells the seq ofthe next packet (from other peer) so we can use random increments to prevent spoofing of packets. Or make it harder atleast.
But that's out of the scope of this rant.
If no receipt comes back, the sender transmits the same packet at half the speed of the previous one, and repeats the process, getting slower each time, until it succeeds.
Umm, No. I'm not 100% sure but I think the network devices are dump thingies that talk to each other on predefined carriage frequencies. Thus, you can't really "slow down" the speed to increase possibility to get the packet through. And certainly this has nothing to do with TCP. Resending of failed packets is a Good Thing (TM). They are just sent again untill they reach their destination or the "I give up"-treshold has been reached.
"The difference (in Fast TCP) is in the software and hardware on the sending computer, which continually measures the time it takes for sent packets to arrive and how long acknowledgements take to come back"
This is the only difference? Wow! Shit. We are definetely going to get faster speeds by adding overhead with this calculation.
Now, I'm through with my rant.
I really really would like to see an actual white paper how this works. There has to be more to this. By the sound of just these articles, it seems to me that someone was paid to develop new, faster protocol that would magically be backward compliant with TCP. Finally the persons couldn't come up with anything smart but gobbled together something that might sound plausible.
Of course you can get "more than 6000 times the capacity of ordinary broadband links" by using your very own dedicated parallel LAN links. You just need fast enough computer to handle the TCP stack. You would also need some fricking fast BUS's on you computer to make any use of this bandwith. Remember, the hard drives, mem chips and other storages aren't exactly 'infinite' in speed either.
If the demo consisted only of two computers exchanging data, there would be no need to estimate the speeds as it would be very unlikely to get packet collisions because of disturbance from other network devices. Also, again, that has nothing to do with TCP-stack. Again, this useless speed calculation is just more overhead.
And now I'm rambling.
Shit, why can't i just stop.
I'm angry, that's why
I hope someone would answer me with insight of what am I overlooking. This looks so useless to me.
Bot Assisted Blogging
Heh, I saw this article on Yahoo, and was immediately concerned. Stupid reporters cut out way too much information, and make the people on wee dialup systems think that they'll get the moon.
Anyway, I think this is primarily interesting for people on really fast connections (ranging in hundreds of megabits per second up to gigabits) with relatively large latencies (tens/hundreds of milliseconds as on a transcontinental link rather than nanoseconds/milliseconds like on a LAN), but I'm sure the research will have some effect on LANs and even the standard broadband connection. Impact on dialup and other not-quite-broadband connections would likely be miniscule.
One main issue with TCP is that it uses a "slow start" algorithm, which other people have mentioned. Real TCP stacks probably tweak the algorithm quite a bit, but from the description in Computer Networks (3rd edition, 1996) by Andrew Tannenbaum, TCP packets start off with a small "window"--how much data can be in transit at a time. The window grows exponentially as packets are transmitted and acknowledgements received until a pre-set threshold is reached, and then the window starts growing more slowly (Tannenbaum's example grows exponentially to 32kB at first, then by 1kB per transmitted packet).
If a packet is lost, the process starts over and the threshold is set to half the window size you had before the dropped packet (I imagine many systems reduce the window size by lesser amounts). Now, this particular algorithm can cause quite a bit of nastiness. It's possible the window size will never get very large. This isn't a really huge problem on low-latency links like in a LAN where you get acknowledgements really quickly, but a hyperfast transcontinental link could be reduced to mere kilobits per second even if the percentage of dropped packets is fairly low.
Additionally, this slow start algorithm will eventually force you to restart at a smaller window size. Given enough data, you'll eventually saturate the link and lose a packet, so until the window grows enough again, there will be considerable unused bandwidth. Good TCP stacks would attempt to guess the available link speed and stop growing the window at a certain point.
Smart system administrators can tweak kernel variables to make systems behave better (preventing the window from getting too small, having larger initial thresholds, for instance), but it looks like a lot of work on Fast TCP and related projects is related to making this a more automatic process and growing/reducing the transmit window size in a more intelligent manner.
Congestion control based on roundtrip times is old news but is uncommon AFAIK. What really happens is direct feedback from routers along a transmission's path. This is done in TCP Vegas, which was first proposed in 1994 and I think is fairly common now. The problem with scaling this or any of the other common TCP implementations to high speed/high delay links is the reaction to detected congestion. "Normal" TCP aggressively scales back its send window (send rate) when it detects congestion, usually chopping it in half. The window/rate then grows linearly until something goes wrong again. This results in alot of lost throughput in high-speed networks especially if the amount of "real" congestion is low. The FAST group is working on a new TCP implementation that doesn't react so aggressively to congestion. This is great for those high-speed/low-congestion networks we all wish really existed but is not something you want to use on the always-backed-up Internet. Would probably make things worse.
TCP is extremely bursty - it pumps all the packets it can as fast as it can over the network as soon as the window opens. Then it waits for replies to all the packets. What typically happens is the burst from the NIC overloads the local router causing numerous dropped packets. This gives the imporession to the sending machine that the network is overloaded and results in a ~90% reduction in bandwidth utilization.
The change is to include a timer that allows the NIC to space the initial burst over the entire window. This prevents the overloading at the router and permits the NIC to reach near its theoretical maximum bandwidth.
In tests involving one router, the results were an order of magnitude increase in bandwith utilization. I'd be interested in seeing their test setup to see how they got such dramatic improvements. Normally TCP/IP is not that ineffecient - even with its extreme burstiness.
The number you have dialed is imaginary, please rotate your phone 90 degrees and try again.
This explanation must be somewhat simplistic, because everybody already did some 100 mbps transfers on fast-Ethernet LANs (even with a couple of routers), and we did not notice that the transfer speed was oscillating between 50 and 100 mbps.
Also, the latency of the link won't influence things significantly (I have 25 mbps at work, and if I can find something that has at least 25 mbps too, I can do FTP at 3 megabytes/s with constant speed).
Unless, of course, when talking about "high-speed" you mean the 1-100 gbps, and "high-latency" more than 1s... I don't have real life experience with those yet.
The numbers mentionned are clearly wrong (6000x speedup? are we joking?), and this reminds me of an article I read some times ago, boasting noticeable performance improvements when increasing MTU (packet size) on networks. Of course, larger packets means less overhead ; but the numbers and figures where completely biased - first, they were only simulations ; second, their "optimized" protocol achieved 100 mbps, and the "plain" FTP achieved not even half of that - well, again, everybody has already achieved 100 mbps speed with FTP, so there must be some "trick" - I mean, some tweaked parameter in the simulation to reduce FTP performance. If this is a real life parameter, very good ; if not, the numbers aren't even worth the bits that describe them...
In any case, the original news seems quite vague and error-prone (again, I tend to be very skeptical when people pretend they achieve high improvements with a protocol that already works at near-wirespeed...)
This explanation must be somewhat simplistic, because everybody already did some 100 mbps transfers on fast-Ethernet LANs (even with a couple of routers), and we did not notice that the transfer speed was oscillating between 50 and 100 mbps.
That's because the oscillation happens so fast that you can't see it happening (or see the next paragraph for an alternate explanation). I mean, it is not a disputed fact that TCP will frequently halve its window during a large file transfer under normal Internet conditions, so there are definitely changes in TX speed that you can't see (your FTP program will probably average over a longer period of time to determine its displayed speed).
As for you saying you got 100 mbps throughput on a 100 mbps line with routers...it's possible that the router is designed to handle that much traffic in its buffer. I think most routers only start barfing when they get lots of traffic on multiple input links, but that's an IIRC, not something I'm sure of.
Agree.
More to the point, the reason you lost a packet is likely to be network-wide congestion. If one connection doesn't back off its sending, but keeps sending at the same rate, it relies on other connections slowing down to allow it to do so.
If no connection slowed down, packets would be being dropped all over the place, and total network throughput would decrease.
In other words, this Fast TCP idea seems inherently selfish and will only improve performance for one user over others, not for all users if adopted.
Actually if you read the New Scientist artictle you can see that that's a lie. What they actually did was bundle 10 FastTcp connetions (one must assume on fast lines) togeather and, fairly unsuprisingly, got speeds 6,000 times fast than a broadband connection... wow... 10 high speed lines are faster than broadband??
This would be more interesting had they actually tested it on a standard 512kbs connection and seen if there was a speed increase. IMO it most likely would not make a huge a difference anyway since alot of the slowdown on a consumer broadband connecting is the connection buffers at your ISP. For a better explanation read the Traffic Shaping HOWTO.
Any good reason not to just use SCP? I know you can transfer files in the same SSH window (using zmodem), but it wouldn't take too much work to modify the SSH client to start a file copy over the current connection using SCP...
So what's the advantage here?
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
Seems to me that the overhead required to estimate your speed would make small downloads slower. Since 99% of our downloads (web pages, images, etc.) are relatively small, wouldn't this be worse??
For large downloads, however, it seems there could be some definite advantages.
However, when it comes to transferring data files, I'd personally be happy sticking with the slower old version of TCP. Who would like to have a file 600 gigs in size that potentially has errors in it, and cannot be trusted? It really has problems when your calculating mountains of data to estimate future stock values, or something else requiring massive amounts of accurate data. An error here or there may not matter, but then again, it may, and you can't tell if there are errors in it or not.
9 23 4&mode=thread
Now, this may help with streaming content, such as perhaps streaming on demand high quality video. This may help in the future with an on demand video system much like Pay-Per-View, but over the internet. Though, lets not forget that Snail Mail is still beating out the Internet.
http://slashdot.org/article.pl?sid=02/09/23/171
A friend of mine posted this article to a private mailing list yesterday. I had the following to say.
Come on, don't buy into the media's interpretation of things. I am not saying the research is bogus, just the article makes things sound different then things are. If a physical wire operates at 1.5MHz serial, there is no way to transmit more than 1.5Mbit/s over that link. Obviously anyone who attempts to sell you software that does so is pulling your chain. That said, Fast TCP is about four times faster than Linux's TCP stack on a 1Gbit/s link (how many people do you know that have one of those). That is because most existing TCP stacks do not perform well at high speeds over long distances, because the demand hasn't been there yet.
Now with that said, different TCP's do make a big difference because of TCP's built in congestion control. The basic idea of congestion control is that a computer shouldn't send data faster than the routers along the path can handle. There are formal proofs that also show that TCP's congestion control guarentees that all TCP connections (using the same implementation and equal round trip times) are given equal priority. The basic idea is to pull back the transmit rate when a packet is dropped.
If all the Internet used UDP, which doesn't have congestion control, our routers would be more overwhelmed than they currently are and everything would slow down.
One can improve one's performance by pulling back less or by taking more than one's fair share.
The statement that all the Internet uses the TCP developed in the 1970's (called TCP Tahoe) is very much false. Most of the Internet runs TCP Reno (1990) now days which includes Jacobson's modification of TCP Tahoe (1988) and added fast recovery and fast retransmit. A number of improvements to that have been discussed in TCP/IP Illustrated by Stevens (1994) and in RFC 2581.
A newer version called TCP Vegas (1995) has been proposed which speeds up performance dramatically and provides a more consistent transmission rate. TCP Vegas hasn't really caught on yet. Fast TCP is a competitor to TCP Vegas.
If you are still reading at this point I will give a more thorough explanation. Whenever a recipient receives a packet it sends an ACK to the sender with the packet it is expecting next.
When TCP starts out it starts in a mode called "slow start." It starts off with a window size of 1, meaning it sends one packet and then waits for the ACK. In slow start mode it increases the window size by one each time an ACK is received until a packet is dropped. So next round it transmits 2, then 4, then 8, until it hits the threshold (Stevens[1994] suggests 65Kbytes). Once it hits the threshold it enters "collision avoidance" mode and increases the window size by one each round (each ACK by 1/window size).
If a sender transmits packets and does not receive any ACKs by the time the timeout for the first packet occurs it pulls back all the way to a windows size of one and drops the threshold in half in both TCP Tahoe and Reno. After going back to one, they start "slow start" again growing the window size exponentially. The difference lies when one packet is dropped but the next few packets are received in a timely manner. In this situation the receiver will send back what is called a triple-ACK all stating it is expecting the missing packet. When a triple-ACK is received TCP Tahoe behaves the same as a timeout (window size to one, threshold in half, slow start), while TCP Reno cuts both the window and the threshold in half, then enters collision avoidance mode.
TCP Vegas works totally differently. It measures round trip time and keeps track of the difference between expected and actual round trip time. If the difference is more than a certain amount it adjusts the window size in the appropriate direction. This method even detects router congestion before the routers start dropping packets in some cases. TCP Vegas also retransmits at a double-ACK
This message is encrypted with Quad ROT-13 to protect the author's copyright under the DMCA.