Yes, but not every site you visit will transfer at this speed. Very few people are going to want to pay higher prices for a technology they can only take half the advantages of. Once this sort of thing becomes mainstream for servers, there MAY be a price increase to deal with additional bandwith.
ISP's won't benefit from this technology as much as subscription websites will. For example, downloading a movie in seconds instead of hours, we could then rent movies online and stream them in their entirety. It will become a lot easier to distribute content like that.
ISP's won't benefit from this technology as much as subscription websites will. For example, downloading a movie in seconds instead of hours, we could then rent movies online and stream them in their entirety. It will become a lot easier to distribute content like that.
I'm no hero. Never was, never will be. I'm just an old killer, hired to do some wet work.
It will also increase Pirating. Downloading tons of movies really fast, burning them, and then watching them almost instantly really.
Wanting a game, go out, download it in moments, and then be playing it in less time then it takes to go to Jumbo Video and back.
Wanting a game, go out, download it in moments, and then be playing it in less time then it takes to go to Jumbo Video and back.
"We're not retreating, we're advancing towards future victory!" - Sarge, Red vs. Blue web series.
This would redefine the internet as we know it, not to mention redefine the limits of piracy ;)
- Me, two hours ago.
- Me, two hours ago.
I'm no hero. Never was, never will be. I'm just an old killer, hired to do some wet work.
Sorry, I read Piracy as "Privicy" which.. is acurate anyways.
"We're not retreating, we're advancing towards future victory!" - Sarge, Red vs. Blue web series.
The press release on Fast TCP is misleading, so I'd like to attempt a more detailed explanation. You'll have to forgive me if my description is telling you something you already know--I'm trying for clarity.
Background
For starters, note that the proposed change is to TCP. Without getting into the details of networking layers, it's enough to simply consider what roles TCP performs. TCP is primarily concerned with reliability and congestion control.
Reliability is handled through the use of acknowledgements (ACKs). You send a TCP packet to another host; that host responds with an ACK, so that you know that your packet was received. If you don't receive an ACK within a timeout period, you assume that your packet was lost in the network and retransmit.
Congestion control is a related concept. TCP itself has no explicit speed limit. Instead, it reacts to feedback from the network. Essentially, the way that TCP's congestion control works is by trying to play nice and share well with others.
TCP achieves this goal through the use of a congestion control window. This window is a fluctuating value that says: how much unacknowledged data am I allowed to have in the network for this flow? (Each active TCP connection is its own flow with its own window size.) If my window size is 15,000 bytes and I've sent 10 1500-byte packets without receiving an ACK, I'm going to wait before sending more data.
So far, so good. Now the question becomes: how does that window size fluctuate? Each time that you receive an ACK, that's a sign that the network is able to handle your traffic, so you increase your window size by the size of the packet that has just been acknowledged. On the other hand, when you lose a packet, that's a sign that the network is congested, so you try be a good citizen by cutting your window size in half.
Essentially, TCP is always creeping up on the gas pedal until there's a packet drop. Then it slams on the brakes and slowly starts ramping up again.
(I've simplified a few ideas and left out some related mechanisms; but that's the gist of it.)
Fast TCP
TCP is a well-established technology. It has been refined several times over the years; but it is known to work very well for traditional networks.
The problem that Fast TCP attemps to solve is that TCP's congestion control algorithm is not well suited for very high speed networks, potentially resulting in underutilized links. That is to say, even when there is bandwidth available, TCP may be reducing traffic too aggressively, resulting in unused bandwidth.
Fast TCP introduces a few ideas. Instead of only using packet loss as an implicit indicator of congestion, it also uses packet delay. (Note that delay is also an implicit indicator of network conditions; Fast TCP does not require network devices to take any new actions.) When recovering from mass packet loss (which is not uncommon at high data rates), delay is not used as indicator of congestion.
The algorithm also attempts to limit burstiness, which is a traffic pattern in which many packets are sent at once, followed by a pause. Fast TCP employs some kind of traffic shaper to inject packets into the network at a steadier rate.
I didn't see the details of the algorithm, so I've had to be light on specifics, but those are the basic concepts.
Conclusions
While Fast TCP is an interesting proposal, with some positive preliminary results, the press report is grossly misleading as relates to current networks. It is worthwhile for people to attempt to optimize TCP for high speed networks. Why would you prefer to leave idle bandwidth on your OC 192 line when there is a customer willing to pay for your service?
However, this technology has nothing to do with getting movies into your home in 5 seconds using your current hardware. It does not create network capacity out of thin air between your computer and the big bad Internet. Tweaking TCP so that it can reach the capacity of high-bandwidth links means nothing if you were already reaching the capacity of your cable modem, the server with which you were communicating, or the intermediary network.
Links
Caltech's page for this project.
The most useful paper that I found from Caltech on the topic.
Another proposal for tailoring TCP to also efficiently accomodate high-speed networks.
Background
For starters, note that the proposed change is to TCP. Without getting into the details of networking layers, it's enough to simply consider what roles TCP performs. TCP is primarily concerned with reliability and congestion control.
Reliability is handled through the use of acknowledgements (ACKs). You send a TCP packet to another host; that host responds with an ACK, so that you know that your packet was received. If you don't receive an ACK within a timeout period, you assume that your packet was lost in the network and retransmit.
Congestion control is a related concept. TCP itself has no explicit speed limit. Instead, it reacts to feedback from the network. Essentially, the way that TCP's congestion control works is by trying to play nice and share well with others.
TCP achieves this goal through the use of a congestion control window. This window is a fluctuating value that says: how much unacknowledged data am I allowed to have in the network for this flow? (Each active TCP connection is its own flow with its own window size.) If my window size is 15,000 bytes and I've sent 10 1500-byte packets without receiving an ACK, I'm going to wait before sending more data.
So far, so good. Now the question becomes: how does that window size fluctuate? Each time that you receive an ACK, that's a sign that the network is able to handle your traffic, so you increase your window size by the size of the packet that has just been acknowledged. On the other hand, when you lose a packet, that's a sign that the network is congested, so you try be a good citizen by cutting your window size in half.
Essentially, TCP is always creeping up on the gas pedal until there's a packet drop. Then it slams on the brakes and slowly starts ramping up again.
(I've simplified a few ideas and left out some related mechanisms; but that's the gist of it.)
Fast TCP
TCP is a well-established technology. It has been refined several times over the years; but it is known to work very well for traditional networks.
The problem that Fast TCP attemps to solve is that TCP's congestion control algorithm is not well suited for very high speed networks, potentially resulting in underutilized links. That is to say, even when there is bandwidth available, TCP may be reducing traffic too aggressively, resulting in unused bandwidth.
Fast TCP introduces a few ideas. Instead of only using packet loss as an implicit indicator of congestion, it also uses packet delay. (Note that delay is also an implicit indicator of network conditions; Fast TCP does not require network devices to take any new actions.) When recovering from mass packet loss (which is not uncommon at high data rates), delay is not used as indicator of congestion.
The algorithm also attempts to limit burstiness, which is a traffic pattern in which many packets are sent at once, followed by a pause. Fast TCP employs some kind of traffic shaper to inject packets into the network at a steadier rate.
I didn't see the details of the algorithm, so I've had to be light on specifics, but those are the basic concepts.
Conclusions
While Fast TCP is an interesting proposal, with some positive preliminary results, the press report is grossly misleading as relates to current networks. It is worthwhile for people to attempt to optimize TCP for high speed networks. Why would you prefer to leave idle bandwidth on your OC 192 line when there is a customer willing to pay for your service?
However, this technology has nothing to do with getting movies into your home in 5 seconds using your current hardware. It does not create network capacity out of thin air between your computer and the big bad Internet. Tweaking TCP so that it can reach the capacity of high-bandwidth links means nothing if you were already reaching the capacity of your cable modem, the server with which you were communicating, or the intermediary network.
Links
Caltech's page for this project.
The most useful paper that I found from Caltech on the topic.
Another proposal for tailoring TCP to also efficiently accomodate high-speed networks.
Thanks for the, uh, essay Chic, and HAPPY BIRTHDAY! It's true, the media is vastly confused when it comes to this subject.
I think the major thing to highlight is that this new technology is not being referred to as Internet 2. That's a communication error. The article in fact deals only with Fast TCP that Chic was talking about. Where the media probably got confused is the Internet 2 project connecting around 200 universities across the country together. Internet 2 does allow for the sort of transfer speeds quoted in the article, especially if it was coupled with streamlined server software.
But, in essence, even if we could transfer a full length movie in 5 seconds, it would still be impossible, simply because hard drives cannot (at this time) write that fast. There are still some hardware limitations.
I think the major thing to highlight is that this new technology is not being referred to as Internet 2. That's a communication error. The article in fact deals only with Fast TCP that Chic was talking about. Where the media probably got confused is the Internet 2 project connecting around 200 universities across the country together. Internet 2 does allow for the sort of transfer speeds quoted in the article, especially if it was coupled with streamlined server software.
But, in essence, even if we could transfer a full length movie in 5 seconds, it would still be impossible, simply because hard drives cannot (at this time) write that fast. There are still some hardware limitations.
I'm no hero. Never was, never will be. I'm just an old killer, hired to do some wet work.
Is your Teenager having too much ORAL SEX!
"We're not retreating, we're advancing towards future victory!" - Sarge, Red vs. Blue web series.
You stole that link from me you bastard!
I'm no hero. Never was, never will be. I'm just an old killer, hired to do some wet work.
This is probably the funniest damn thing I've ever seen (Not safe for the youngins). This one is actually kind of scary, good thing she missed... and here's another video link.
I'm no hero. Never was, never will be. I'm just an old killer, hired to do some wet work.
Hah, that first one was quite funny. I saw something like that on TV a few weeks ago. The reporter was trying to do a serious segment, and two guys were foolling around in the background. One of them fake-punched the other guy, and he went flying, it was hilarious.
"Hey, you! If you meet a beautiful, seductive woman who's looking for me, tell her 'hi.' Anyway, I don't think a woman like that would be looking for me." -Guy in Fourside Hotel
It came from Linksville!