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.

Comments

Protocol faster than DSL?

[dodald]

How can a protocol be rated faster than DSL? Shouldn't the rating be against another protocol? Did I miss something in the article?

Re:Protocol faster than DSL?

[wankledot]

Comparing it to DSL (and POTS) was really stupid, IMO, but they needed something that would connect with the average reader (I guess.) They don't say anything about what kind of physical/data/ layers the thing runs on. Comparing it to DSL and modems leads the novice reader to think it works on POTS lines, which I'm sure is not the case.

Neat stuff, stupid stupid article.

Re:Protocol faster than DSL?

[Dun Malg]

That was my first thought. Isn't that like saying that they've invented gasoline that goes faster than a car?

Or like saying they've invented a vehicle that goes faster than a NASCAR racetrack.

Re:Protocol faster than DSL?

[jimbosworldorg]

I *think* what they're trying to say is that BIC-TCP can utilize high-speed networks a lot better than plain-vanilla TCP/IP. But I don't know what the heck DSL is supposed to have to do with it; the physical *medium* consumer DSL uses (copper POTS lines) sure as hell isn't going to support a 9Gbps connection...

Re:Protocol faster than DSL?

[morcheeba]

Yep, it looks like the article makes no sense at all.

Dr. Rhee, 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. 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.

Apples and Oranges?

[Ars-Fartsica]

When did a protocol become "faster" than a transmission technology?

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.

DSL speed vs IP speed

[DaveRobb]

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.

Re:Summary: BIC-TCP is an efficient TCP successor

[zalas]

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.

Mike's oversimplified take on things.

[IvyMike]

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.

Clarification

[Percy_Blakeney]

It seems that the protocol is meant to decrease the amount of time it takes to fully utilize a certain (large) amount of bandwidth. TCP isn't designed to quickly utilize huge amounts of bandwidth, so they are compensating for that. To quote from their site:

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.

Totally false title

[TA]

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.