Slashdot Mirror

← Back to Stories (view on slashdot.org)

Fast TCP To Increase Speed Of File Transfers?

Posted by simoniker on from the turbocharge-your-interweb dept.

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.

19 of 401 comments (clear)

  1. Isn't this called UDP? by havaloc · · Score: 5, Insightful

    Let's see. Transmission without error-checking is called UDP, isn't it?

    1. Re:Isn't this called UDP? by harvardian · · Score: 5, Informative

      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.

    2. Re:Isn't this called UDP? by harvardian · · Score: 5, Informative
      FYI, a great website for understanding how TCP congestion control works is here. It explains how TCP additively increases its window size as traffic goes through okay but then halves its window size when it runs into a problem.

      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:
      It is rare that a packet is dropped because of an error during transmission. Therefore, TCP interprets timeouts as a sign of congestion, and reduces the rate at which it is transmitting.
      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.
    3. Re:Isn't this called UDP? by tincho_uy · · Score: 5, Informative

      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

  2. zmodem??? by case_igl · · Score: 5, Interesting

    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.

  3. Uh oh... by ctishman · · Score: 5, Funny

    "Caltech is already in talks with Microsoft and Disney about using it for video on demand," the magazine added. "Hey! Let's take a technology that's potentially revolutionary, and give it to Microsoft!" Yay for Caltech!

  4. Re:stupid non network guy question by Poofat · · Score: 5, Informative

    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

  5. Great! by Lu+Xun · · Score: 5, Funny

    Who needs erro>*H~@}&)aA=cking anyway?

    --
    That's not a soda... it's a caffeine delivery device!
  6. not optimistic by ravinfinite · · Score: 5, Insightful

    "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.

  7. There is a reason why TCP throttles itself by Madwand · · Score: 5, Insightful

    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...

  8. Fixes problems with slow-start and resends.... by malfunct · · Score: 5, Informative
    It looks like this protocol is more proactive in monitoring the line. It looks for clues that it needs to slow down before a packet gets lost. A great deal of time in a TCP connection is spent waiting for acks and resending data, this is made worse by the typical latency across then net (if I remember right it averages 30 to 800 ms for domestic connections depending on time of day, and between 700 and like 1200 for connections abroad).

    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,"

  9. You just need to hire the right marketing team... by Anonymous Coward · · Score: 5, Funny

    ... to get a good name for this technology.

    With Microsoft's, it would be ActiveTCP.

    With Intel's, it would be HyperTCP.

    And so on, and so forth.

  10. Man! by nhaines · · Score: 5, Funny

    If only I were using Fast TCP, this could have been first post!

  11. Re:uh BitTorrent? by ogre2112 · · Score: 5, Funny

    I foresee BitTorrent as being the next Slashdot craze. (See: Beowulf, Natalie Portman. . .)

    "Hey! This article is great! Imagine how BitTorrent would help it!"

  12. Article is inaccurate and misleading by zeds · · Score: 5, Interesting
    The New scientist writer clearly has no understanding of how TCP/IP or the Internet work in general and how Caltech's FAST could improve data transfer efficiency. His sensationalist claims that this could enable downloading a dvd in seconds are so much ignorant crap. 6000x faster than broadband? That has more to do with the fact they used an INCREDIBLY FAT PIPE (a 10gigabit connection), probably in a laboratory setting, than any of FAST's optimizations. It's true TCP/IP's efficiency maxes out at a certain rate, but that doesn't really matter in the real world, because nobody is actually downloading movies from dedicated 10gigabit links to the backbone. Not to mention that you won't see anyone serving anything at these speeds for the next decade or so. I wonder what this suggests about the accuracy of articles on subjects I know nothing about. It's an academic curiosity folks.

    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.

  13. Re:You just need to hire the right marketing team. by pantropik · · Score: 5, Funny

    I don't know why they don't just get nVidia to design it. That way the sending machine will only send the packets it thinks you're actually going to be able to see instead of the entire datastream.

    nTCP = instant speed increase.

  14. Error Checking by DASHSL0T · · Score: 5, Funny

    Error checking hasn't been removed from TCP; we've removed it from Slashdot story summaries instead, speeding up the posting by nearly 6000x.
    --
    Linux-Universe

    --
    Freedom Is Universal
    Linux-Universe
  15. Eliminating 'burstiness' of TCP/IP by Daniel_ · · Score: 5, Interesting
    If I'm reading the article right, they're using the same technique that a doctoral candidate did his Phd thesis on at OSU about 3 years ago.

    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.
  16. Re:6000 TIMES !!! by elem · · Score: 5, Interesting

    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.