Slashdot Mirror
BIC-TCP 6,000 Times Quicker Than DSL
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.
How can a protocol be rated faster than DSL? Shouldn't the rating be against another protocol? Did I miss something in the article?
101010b 2Ah 52o
This is a very impressive development... but I have to wonder. Current home computers would have no chance of even processing fast enough to keep up with that speed. I wonder how long it would take to get to the point that they would?
However, the idea is exciting... imagine! Internet at the speed of computer.
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.
This article somewhat erroneously compares the speed of "DSL" vs the speed of "BIC-TCP". DSL is a link-layer protocol. BIC-TCP is an network layer protocol. These are different things. See http://www.webopedia.com/quick_ref/OSI_Layers.asp for details.
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.
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?
I think a better summary would be that this is not entirely a new protocol. Rather, it's a variant on TCP with changes to the window increasing portion of the code. Basically, they claim that there currently exists an unfairness in allocation of bandwidth of two connections sharing a pipe. Basically that having different round trip times causes them to share the bandwidth unfairly. Their protocol supposedly alleviates this problem in high bandwidth pipes whereas TCP does not.
Ok, the article (especially the "6000x faster than DSL") doesn't make a whole lot of sense. Here's my take on it: they're talking about a new congestion avoidance mechanism.
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 (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, which I believe is a different solution to the same problems.
It's not the US's fault that your country's ISP's are dickheads.
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.
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.
This is true, poeple will buy a great CD player and spent 30 pounds on a top-notch cable with gold banana plugs and the lot to connect it to their amp. The quality, however, will be lost in the crap wiring from the plug on the back of the amp to the circuit board.
It's just one of those daft things that's sprung up from 'net culture, like smileys, TLAs*, ETLAs**, and l33t 5p34k. A while back the term "Grilfiend" was in popular use for "girlfriend", and "the" is often deliberately misspelt as "teh". At least some of these things drop out of use from time to time - it's been a while since I saw "K-rad" or "Dewd". Now if we could only rid ourselves of "boi" the world would be a marginally better place.
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)
Curiosity was framed. Ignorance killed the cat.
Shame on whoever put that title ("Faster than DSL") on this
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.
well, yeah.
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.
Why, yes, I AM a Pagan Libertarian.