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.

5 of 401 comments (clear)

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

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

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

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