Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
The Internet Technology Science

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.
This discussion has been archived. No new comments can be posted.

BIC-TCP 6,000 Times Quicker Than DSL

Comments Filter:
  • by dodald ( 195775 ) * on Monday March 15, 2004 @07:51PM (#8573641) Homepage
    How can a protocol be rated faster than DSL? Shouldn't the rating be against another protocol? Did I miss something in the article?
  • by BenSpinSpace ( 683543 ) on Monday March 15, 2004 @07:53PM (#8573674)
    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.
  • by wankledot ( 712148 ) on Monday March 15, 2004 @07:54PM (#8573681)
    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.

  • by Ars-Fartsica ( 166957 ) on Monday March 15, 2004 @07:56PM (#8573712)
    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.

  • by Dun Malg ( 230075 ) on Monday March 15, 2004 @07:58PM (#8573735) Homepage
    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.

  • by DaveRobb ( 139653 ) on Monday March 15, 2004 @07:59PM (#8573744)
    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 [] 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.

  • by jimbosworldorg ( 615112 ) <slashdot@jimbosw o r l d . o rg> on Monday March 15, 2004 @08:02PM (#8573765) Homepage
    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...
  • by morcheeba ( 260908 ) * on Monday March 15, 2004 @08:03PM (#8573773) Journal
    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.
  • Wrong date? (Score:2, Insightful)

    by embedded_C ( 653649 ) on Monday March 15, 2004 @08:07PM (#8573824)

    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?

  • by zalas ( 682627 ) on Monday March 15, 2004 @08:13PM (#8573867) Homepage
    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.
  • by IvyMike ( 178408 ) on Monday March 15, 2004 @08:26PM (#8573979)
    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.
  • by Anonymous Coward on Monday March 15, 2004 @08:27PM (#8573988)
    It's not the US's fault that your country's ISP's are dickheads.
  • Clarification (Score:5, Insightful)

    by Percy_Blakeney ( 542178 ) on Monday March 15, 2004 @08:31PM (#8574022) Homepage
    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.

  • by Percy_Blakeney ( 542178 ) on Monday March 15, 2004 @08:43PM (#8574119) Homepage
    They can put as much data on the wire as they want, but it will still take 100 ms and 25 hops to get there.

    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.

  • by ffub ( 322605 ) on Monday March 15, 2004 @08:54PM (#8574199)
    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.
  • by Pieroxy ( 222434 ) on Monday March 15, 2004 @09:19PM (#8574354) Homepage
    the physical *medium* consumer DSL uses (copper POTS lines) sure as hell isn't going to support a 9Gbps connection

    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!
  • by SoSueMe ( 263478 ) on Monday March 15, 2004 @09:23PM (#8574380)
    Not to dampen the hillarity, which I'm sure will continue to ensue, but the comparison seems to be for referential purposes rather than a direct comparison of protocols.
    If I didn't know how fast 100 kph or 62 mph were, would I know they were equal?
  • by robotoverflow ( 738751 ) on Monday March 15, 2004 @10:31PM (#8574883)
    Or like saying they've invented a vehicle that goes faster than a NASCAR racetrack.

    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.
  • by RichardX ( 457979 ) on Tuesday March 16, 2004 @07:27AM (#8576903) Homepage
    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)
  • by TA ( 14109 ) on Tuesday March 16, 2004 @08:16AM (#8577039)
    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

    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
    (see 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.
  • by Lennie ( 16154 ) on Tuesday March 16, 2004 @10:19AM (#8577711)
    People keep saying TCP/IP, great, but they forget UDP.

    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.
  • by paganizer ( 566360 ) <.moc.liamtoh. .ta. .1evorgeht.> on Tuesday March 16, 2004 @11:36AM (#8578412) Homepage Journal
    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.

Loose bits sink chips.