BIC-TCP 6,000 Times Quicker Than DSL 381
An anonymous reader writes "North Carolina researchers have developed an Internet protocol, subsequently tested and affirmed by Stanford, that hums along at speeds roughly 6,000 times that of DSL. The system, called BIC-TCP, beat out competing protocols from Caltech, University College London and others. The results were announced at IEEE's annual communications confab in Hong Kong." Update: 03/16 04:46 GMT by T : ScienceBlog suggests this alternate link while their site is down.
Protocol faster than DSL? (Score:5, Insightful)
Yikes! How can a home user tell? (Score:2, Insightful)
However, the idea is exciting... imagine! Internet at the speed of computer.
Re:Protocol faster than DSL? (Score:5, Insightful)
Neat stuff, stupid stupid article.
Apples and Oranges? (Score:5, Insightful)
The article is /.'d so I can't figure out wht this means - what transmission media/hardware are they using? I can make plain old TCP/IP 600,000 times faster than "DSL speeds" if I have hardware that meets that specification.
Re:Protocol faster than DSL? (Score:5, Insightful)
Or like saying they've invented a vehicle that goes faster than a NASCAR racetrack.
DSL speed vs IP speed (Score:5, Insightful)
The question I'd love to ask the authors would be "so, what happens when I run BIC-TCP over a DSL modem? Does it suddenly become 6000 times faster?" I don't think so.
Connections are still going to be constrained by the underlying link speed, and the internet will not become thousands of times faster overnight because of this.
Sure, BIC-TCP looks like it's more efficient than TCP and that's a good thing, but the gains this protocol provides over TCP are in scalability when using suitably big links.
Re:Protocol faster than DSL? (Score:5, Insightful)
Re:Protocol faster than DSL? (Score:5, Insightful)
Dr. Rhee [ncsu.edu], who made that comparison, also made another factual error: "TCP was originally designed in the 1980s when Internet speeds were much slower and bandwidths much smaller" -- Tcp was actually invented in 1974. [about.com] Not that major, but you wouldn't expect a guy who "has been researching network congestion solutions for at least a decade" to miss the mark by so much.
Hopefully the reporter was confused, but since it was a press release, you'd think that it would have had time to go through some review.
Wrong date? (Score:2, Insightful)
The problem, Rhee said, is the inherent limitations of regular TCP. "TCP was originally designed in the 1980s when Internet speeds were much slower and bandwidths much smaller," he said.
Doesn't he mean the 1970s?
Re:Summary: BIC-TCP is an efficient TCP successor (Score:5, Insightful)
Mike's oversimplified take on things. (Score:5, Insightful)
Here's a super-simplified version of the problem they're trying to solve: Imagine you have a 3Mbps link to your ISP, as do 49 of your neighbors. However, your ISP has a 45Mbps T3 link to the outside internet. What happens when everybody on your ISP trys to download the Half-Life 2 demo at the same time, creating a need for for 150 Mbps at the ISP uplink? This is called congestion.
There are various solutions that you can use for congestion avoidance; you may have heard of TCP Vegas and Reno [psu.edu] (I'm linking to the PDF document, because it contains a lot of math. This should also be a signal to you about how ridiculously siplified my explanation above is). Obviously, when there is congestion, somebody's got to wait, but determining who and how is not as easy as it might seem.
The new part of the problem is: today's fast networks have very different bandwidth and latency ratios to the networks of even five years ago. Vegas and Reno congestion avoidance algorithms don't work as well as they used to under these conditions. This paper presents a solution that does work well on today's high-speed networks. (Maybe somebody with more expertise could pipe in here with a discussion of "why the existing mechanisms don't work well, and how the new solutions address the problem"?)
I believe slashdot has already covered FAST [caltech.edu], which I believe is a different solution to the same problems.
Re:please don't do this. (Score:1, Insightful)
Clarification (Score:5, Insightful)
In order for TCP to increase its window for full utilization of 10Gbps with 1500-byte packets, it requires over 83,333 RTTs [round trip times]. With 100ms RTT, it takes approximately 1.5 hours...
If I understand correctly, they are not making the inherent speed faster, they are just making the protocol able to understand the nature of the bandwidth more quickly, thus improving its ability to efficiently utilize the bandwidth. Thus, instead of requiring 1.5 hours to ramp up, theirs might take a few seconds or minutes.
My guess is that you aren't going to see huge gains from this for the average person; you'd need scads and scads of bandwidth in order to really need something like this -- TCP doesn't have any problem saturating a small 56kbps.
Re:Propagation delays (Score:3, Insightful)
That's the point, though; they're trying to put data on the wire more often than before. TCP doesn't start out by saturating the wire, but instead slowly "tests the water" and transfers data more and more frequently until it is confident it has saturated the line.
This protocol, on the other hand, figures out the capacity of the line faster, and thus can saturate it more quickly. The difference between the two is where they get their weird "6000x" figure.
Re:Propagation delays (Score:2, Insightful)
Re:Protocol faster than DSL? (Score:3, Insightful)
Sure, and the earth is flat. Did anyone believe that you could go faster than 56k before they unleashed DSL? Now that DLS is out, why couldn't they come up with another technology that would go 6k times faster?
Open up!
Re:Protocol faster than DSL? (Score:2, Insightful)
If I didn't know how fast 100 kph or 62 mph were, would I know they were equal?
Re:Protocol faster than DSL? (Score:2, Insightful)
Put any car on a racetrack filled with pot-holes and the car won't be able to get anywhere very quickly, will it? With this protocol these guys have made a smoother road.
Re:Time to Implimentation? (Score:3, Insightful)
I suppose it's possible some people say pr0n instead of porn to try and circumvent their company's internet filters, but unlikely.
*TLA - Three Letter Acronym
**ETLA - Extended Three Letter Acronym (Any acronym with more than three letters)
Totally false title (Score:3, Insightful)
posting. This is much worse than comparing apples and oranges,
it's like saying "a ferrari is faster than a tarmac road".
DSL is a low-level protocol for utilizing the copper going to
your house, and nothing in BIC-TCP is going to increase that
speed.
BIC-TCP is a solution for the more and more common problem of
really high bandwidth (say, up to hundreds of megabits, or
gigabits per sec.), combined with relatively long round trip
times. Like e.g. having a fiber from one continent to another,
or high speed satellite links. With standard TCP/IP your
transmission rate will basically be limited to
2^window_size_in_bits/RTT_in_seconds
(see http://www.ieft.org/rfc/rfc1323.txt). Try some calculations
and you'll find that this sucks majorly. BIC-TCP is meant as
a way out of this problem. It won't make your copper go faster.
Re:Protocol faster than DSL? (Score:3, Insightful)
I wouldn't want an internet without having UDP/port 53 (DNS), that wouldn't be much fun, trust me, although maybe I could be able to remember the IP-addresses of google if I really wanted to.
That would help.
Re:Time to Implimentation? (Score:3, Insightful)
That was sort of my point.
A protocol as described has no real bearing on how fat your pipe is.
If you run the protocol over a T1 or DSL connection, you aren't going to see any obvious difference in speed.