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.

381 comments

  1. Time to Implimentation? by Null_Packet · · Score: 5, Interesting

    It would be interesting to know how far out an implimentation of such a protocol on a large scale is.

    1. Re:Time to Implimentation? by ackthpt · · Score: 5, Funny
      It would be interesting to know how far out an implimentation of such a protocol on a large scale is.

      As we all know, pr0n drives the technology bubble. Indicate that the average luser could watch internet pr0n real time over a 56K modem and it's just a matter of time.

      --

      A feeling of having made the same mistake before: Deja Foobar
    2. Re:Time to Implimentation? by metlin · · Score: 0, Redundant

      Am sure we have enough pr0n around to test that ;-)

      So other than all the cool thingys blah blah, imagine what this would do for the future of the pr0n industry! :-O

      *gasps*

    3. Re:Time to Implimentation? by Zareste · · Score: 3, Interesting

      No doubt they've already gotten a slew of calls from the MATRIX psychos, eh?

      --
      I am NOT a number! I am a - oh wait, I'm number 761710. Look! 761710!
    4. Re:Time to Implimentation? by km790816 · · Score: 4, Informative

      For those that found a dead link, a better article: 'Better' TCP Invented

      Researchers in North Carolina State University's Department of Computer Science have developed a new data transfer protocol for the Internet that makes today's high-speed Digital Subscriber Line (DSL) connections seem lethargic.

    5. Re:Time to Implimentation? by Anonymous Coward · · Score: 0

      Please, for the love of god! It is implementation, not implimentation. If I have to see this word misspelled one more time, I have to barf.

      Dictionaries are your best friend!

    6. Re:Time to Implimentation? by asldihf · · Score: 1

      Orbital Data (www.orbitaldata.com) has an advanced implementation of TCP/IP that is packaged as an appliance. Data rates as high as 300mbs over the internet through loss/latency.

    7. Re:Time to Implimentation? by paganizer · · Score: 1

      That is what it seems to imply, isn't it?
      I'm slightly shocked that /. made the mistake of running this; saying that "BIC-TCP 6,000 Times Quicker Than DSL" is pretty much like saying that, um, Interstate 101 can carry 6,000 times more vehicles than a moped"

      Or that "Hoover dam generates 6000 times more electricity than my coffeemaker"

      Hey, thats kinda fun.

      --
      Why, yes, I AM a Pagan Libertarian.
    8. Re:Time to Implimentation? by AndyAMPohl · · Score: 1

      why do people say pr0n? do you mean porn, or is that something else? wtf is pr0n? forgive my ignorance, and perhaps keep it out of the forum... iono i'm just curious.

    9. Re:Time to Implimentation? by RichardX · · Score: 2, Insightful

      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.
    10. Re:Time to Implimentation? by ConceptJunkie · · Score: 1

      I only understand bandwidth in terms of LoC's.

      Now, if I only had one to test it with.

      --
      You are in a maze of twisty little passages, all alike.
    11. Re:Time to Implimentation? by anti-trojan · · Score: 2, Funny

      Lucky you. My coffeemaker consumes electricity.

    12. Re:Time to Implimentation? by Alzheimers · · Score: 1

      But it provides me with energy, which in turn allows me to go to work and purchase the energy required to run it.

      Perpetual motion, here we come!

    13. Re:Time to Implimentation? by paganizer · · Score: 2, Insightful

      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.
    14. Re:Time to Implimentation? by sparkywonderchicken · · Score: 1

      I thought resistance was E/I. I'm obviously confused.

    15. Re:Time to Implimentation? by shokk · · Score: 1

      I think this fits in just great with the previous story about new ad formats being used at ESPN. Who cares about a 2MB download when it takes more time to think about griping about it.

      --
      "Beware of he who would deny you access to information, for in his heart, he dreams himself your master."
    16. Re:Time to Implimentation? by ackthpt · · Score: 1
      I think this fits in just great with the previous story about new ad formats being used at ESPN. Who cares about a 2MB download when it takes more time to think about griping about it.

      I dunno about ESPN, but I was looking something up on imdb this morning and got a black screen and something about "if the page did not load, click here" which had something on it which looked vaguely like some kind of advertising delivery failure. Maybe imdb is going to insert trailers? It killed my browser (firebird) so I had to terminate the job and start over.

      --

      A feeling of having made the same mistake before: Deja Foobar
    17. Re:Time to Implimentation? by Hard_Code · · Score: 1

      The article indicates that it is indeed a protocol not a new transport medium (err, so Layer 3 instead of Layer 0??). So the analogy is correct but probably could be made more specific by: BIC-TCP/ is 6000 faster than TCP/ for X types of payloads.

      --

      It's 10 PM. Do you know if you're un-American?
    18. Re:Time to Implimentation? by shokk · · Score: 1

      Stuff like this makes me less likely to view these ads, especially when I have to spend an hour cursing the website and anyone related to anyone whoever worked there because my browser died with 10 active tabs.

      --
      "Beware of he who would deny you access to information, for in his heart, he dreams himself your master."
    19. Re:Time to Implimentation? by Anonymous Coward · · Score: 0

      Get Galeon or Opera. If they crash (or are killed, or the power goes out) they restore your old session. Other browsers may do so as well.

  2. Protocol faster than DSL? by dodald · · Score: 5, Insightful

    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
    1. Re:Protocol faster than DSL? by wankledot · · Score: 4, Insightful
      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.

      --
      My sig is blank, I typed this by hand.
    2. Re:Protocol faster than DSL? by dreamchaser · · Score: 5, Funny

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

    3. Re:Protocol faster than DSL? by Anonymous Coward · · Score: 1, Informative

      They are different. DSL is a Layer 5 protocol, a datagram-based
      protocol, that provides for global addressing independent of ATM's
      scheme, routes packets independently of ATM's routing, and is used as
      the foundation for all Internet Protocol communications. IP can be used
      over ATM or over virtually any other link layer.

      DSL is layered on top of IP. It is a Layer 5 protocol, specifically
      designed to provide for "error free" communications. TCP has built-in
      error check, acknowledgment, and retry features.

      BIC-TCP is another Layer 4 protocol that can be layered over IP. It
      provides for error checking but not retry, so it isn't "error free" by
      itself.

      So IP over ATM is a more general description than TCP/IP over ATM or
      DSL/IP over ATM, or FTP over TCP/IP over ATM, or HTTP over BIC-TCP/IP over
      ATM, .... You get the picture.

    4. Re:Protocol faster than DSL? by whitelines · · Score: 1

      Yeah, wouldn't the new protocol be running on top of DSL... The comparison makes no sense.

      --
      /* TBD */
    5. Re:Protocol faster than DSL? by Anonymous Coward · · Score: 0

      Ya missed it 'cause it went by too fast...

      This post brought to you by twoslice =)

    6. Re:Protocol faster than DSL? by PepsiProgrammer · · Score: 1

      I was wondering the same thing, I go to ncsu, and I cant seem to find anything that conclusively says whether this is a hardware standard or a software protocol, as far as I can tell its a software protocol Id really like to see some more technical info about it.

      --
      "The United States has no right, no desire, and no intention to impose our form of government on anyone else." - Bush 05
    7. Re:Protocol faster than DSL? by brion · · Score: 1

      What the article seems to be trying to say is that this protocol works better than TCP/IP does on a heavily-used connection with bandwidth at the level of 6000 times greater than a typical DSL line.

      Nothing to see here, move along... it won't get grits to your home any faster.

      --

      Chu vi parolas Vikipedion?

    8. Re:Protocol faster than DSL? by wankledot · · Score: 4, Funny

      Better yet, they've invented tires for the space shuttle that are capable of going 100k times faster than regular tires. I want some of those tires for my Pinto! They'll make it that much faster!

      --
      My sig is blank, I typed this by hand.
    9. Re:Protocol faster than DSL? by Anonymous Coward · · Score: 0

      pure bullshit. DSL is the foundation of all IP communication? hahaha

    10. Re:Protocol faster than DSL? by Cynikal · · Score: 5, Funny

      thats what i was gonna say... last i heard DSL was physical connection method..

      in other news AMD has developed a new architecture 80 billion times faster than grapefruit

    11. Re:Protocol faster than DSL? by Dun+Malg · · Score: 4, Insightful
      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.

      --
      If a job's not worth doing, it's not worth doing right.
    12. Re:Protocol faster than DSL? by jimbosworldorg · · Score: 5, Insightful

      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...

      --

      Coming soon to Slashdot: meta-meta-moderation!

    13. Re:Protocol faster than DSL? by morcheeba · · Score: 4, Insightful

      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.

    14. Re:Protocol faster than DSL? by dave3138 · · Score: 1

      Wouldn't this be down at good old layer 1? DSL is the physical medium over which the data is delivered...

    15. Re:Protocol faster than DSL? by madbastd · · Score: 2, Interesting
      How can a protocol be rated faster than DSL? Shouldn't the rating be against another protocol?
      DSL is a layer 1 & 2 protocol. TCP and BIC-TCP are layer 4 protocols. So, you're correct that they're not comparing like with like.

      Also, TCP will also reach similar speeds under the right conditions. BIC-TCP will just reach those speeds with less ramp-up time, and over a wider range of conditions. One of those conditions is that it is not running over a DSL line, or a T3 or an OC3 or OC48 or anything that the average internet user will see in the next decade or two. So, the article is wildly over-hyping a minor protocol tweak that is irrelevant to almost all internet users.

    16. Re:Protocol faster than DSL? by Rorschach1 · · Score: 5, Funny
      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...


      Sure it will... provided you're not more than three feet from the central office.

    17. Re:Protocol faster than DSL? by Jayfar · · Score: 2, Interesting

      Naw, physical layer (layer 1) is copper, glass and silicon.

    18. Re:Protocol faster than DSL? by ebrandsberg · · Score: 1

      The peak throughput of a single TCP connection can be computed from various factors, including the TCP window size, latency, etc. As such, they were comparing the peak throughput of a connection to the throughput of various transmission media, although they should have compared it a) against actual bandwidth values, and b) against peak TCP throughput numbers.

      The real truth is that if you have 150K dialup lines all requesting different content on broadband connection (OC3 and the like), then this protocol won't mean squat.

    19. Re:Protocol faster than DSL? by passthecrackpipe · · Score: 0, Offtopic

      heh - from his profile "From 2000 to 2002, Injong was on leave from his university position to found Togabi Technologies, INC, a startup company that specializes in developing and marketing multimedia applications and services for wireless Internet. He served as CTO/CEO of the company before returning to his academic position in 2003."

      Maybe he got sacked as the CTO that didn't manage to make the TCP/IP stack in their chat application work.... ;-)

      --
      People who think they know everything are a great annoyance to those of us who do.
    20. Re:Protocol faster than DSL? by Wakkow · · Score: 4, Funny

      Is that going to make my grandma's grapefruit tree obsolete?

    21. Re:Protocol faster than DSL? by dbrower · · Score: 5, Interesting
      tcp as we know it was NOT invented in 1974 -- that was the original arpanet, before the conversion to the IPv4 internet around 1983. Dr. Rhee is closer to being correct on this point than the confused references.

      Much algorithmic change has happened between the days of the 56k APRANET and multi-gigabit networks also using IP. Van Jacobsen's slow start and other ways of working out tradeoffs on bandwidth/delay vs. window size have been fiddled with for years, and arguably TCP as we know it is too compromised by history to work well as high speeds -- at least, that's what Rhee's comment suggests.

      This is really relevant stuff, not to be dismissed by wannabees.

      -dB

      --
      "It if was easy to do, we'd find someone cheaper than you to do it."
    22. Re:Protocol faster than DSL? by tenchima · · Score: 3, Informative

      I think DSL was originally a predominantly ATM transport layer

      DSL being the physical layer, with a network topology now available of of PPP of either PPPoA (ATM), or PPPoE (Ethernet).

      I guess this BIC-TCP is a new topology option to go with the PPP.

      --
      If at first you don't succeed, so much for skydiving.
    23. Re:Protocol faster than DSL? by Cynikal · · Score: 1

      no, it just goes through her 80 billion times faster.. whether thats a good thing or not is a matter of personal view

    24. Re:Protocol faster than DSL? by iminplaya · · Score: 5, Funny

      I want some of those tires for my Pinto! They'll make it that much faster!

      Yeah, maybe you'll be able to out run the fire in your gas tank. :-)

      --
      What?
    25. Re:Protocol faster than DSL? by drgonzo59 · · Score: 0, Troll
      And I have implemented a protocol that is 7,000 times faster than cable. It works over many parallel fiberoptic channels. Blah blah...

      This article is probably published by Al Gore who, after inventing the Internet, still works on optimizing the speed of many protocols that he came up with back in the day.

    26. Re:Protocol faster than DSL? by ezzzD55J · · Score: 2, Informative

      No, indeed. All this protocol does is increase the rate at which a transport layer protocol (such as TCP) adjusts to available bandwidth over a very fast physical medium (without bumping into the congestion limit, otherwise it would be easy ;)). Numbers such as 6000 and words such as DSL are crazy.

    27. Re:Protocol faster than DSL? by Anonymous Coward · · Score: 0

      Mod parent up as funny. Someone didn't like the "Al Gore" comment I think.

    28. Re:Protocol faster than DSL? by DarthScott · · Score: 1

      or like a chicken that goes faster than an iguana. no wait...not like that.

    29. Re:Protocol faster than DSL? by photon317 · · Score: 2, Informative


      The idea behind researching higher-speed protocols is that if you took plain old TCP and ran it on a line 6000x faster than DSL, you would find that the workings of the protocol itself would become the performance bottleneck in the system. These guys are thinking ahead and writing the protocols we'll need on future faster networks. The blurb _is_ kinda moronic in how it compares a protocol to DSL, but at the same time it is truthful. It would have made more sense if they had made it clearer that the protocol was designed to fully utilize an as-yet-unknown broadband service 6000x faster than DSL that might exist in the future.

      --
      11*43+456^2
    30. Re:Protocol faster than DSL? by Anonymous Coward · · Score: 0

      not if by "grapefruit tree" you mean "beowulf cluster of grapefruits"

    31. Re:Protocol faster than DSL? by Flamingcheeze · · Score: 1

      Screw that. I want an architecture that runs on the voltage/current provided by a grapefruit!

      --
      The Philosophy of Liberty | lewrockwell.com
    32. Re:Protocol faster than DSL? by Cynikal · · Score: 1

      i got an old zx81 that im sure i could mod to do that

    33. Re:Protocol faster than DSL? by MegaThawt · · Score: 1

      In Soviet Russia, the protocol rates You!

      --
      All sigs should be as funny as possible, but no funnier.
    34. Re:Protocol faster than DSL? by Anonymous Coward · · Score: 0

      Basically, yes. But it runs a lot cooler than an AMD. You can prove this to yourself by sitting under it in summer.

    35. Re:Protocol faster than DSL? by BuckaBooBob · · Score: 1

      In other news a New legal proceedure developed by SCO not only gets better gas mileage than your SUV but will also save you a bundle on your insurance :)

      I was waiting for that line to turn up :)

      --
      Who needs WiFi when we can have Packet Over Sheep! http://datacomm.org/PoS-InternetDraft.txt
    36. Re:Protocol faster than DSL? by Pieroxy · · Score: 2, Insightful

      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!

    37. Re:Protocol faster than DSL? by SoSueMe · · Score: 2, Insightful

      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?

    38. Re:Protocol faster than DSL? by Mac+Degger · · Score: 1

      Now that is humour :) Thanks for making me grin out loud :)

      --
      -- Waht? Tehr's a preveiw buottn?
    39. Re:Protocol faster than DSL? by Anonymous Coward · · Score: 0

      Dude, open a freaking physics book. DSL is the max theoretical speed over copper. We won't get any faster until the lines are replaced with fiber. Dumass.

    40. Re:Protocol faster than DSL? by Cramer · · Score: 5, Informative

      DSL is a modulation technology. You can do whatever you want with the bits entering and leaving the modulator/demodulator (mo-dem). Frame Relay and ATM are the predominant "layer2" transports with PPP gaining ground (PPPoKitchenSink is all the rage) and RFC1489(?) bridged ethernet losing ground (which is a shame as it has the lowest protocol overhead of all of them, esp. PPP.)

      What is BIC trying to fix? It certainly isn't "the internet" as most links, on average, run at a fraction of their available bandwidth. TCP can fill up more bandwidth than most people can aford. It looks like the researchers with these insane connections and even more insane data sets want the holy grail of zero protocol overhead and none of the inherent throttling. (TCP limits the number of packets it will transmit before pausing for an ack. As a result, a single TCP connection usually will not consume a gigE link -- 4 connections certainly can.)

    41. Re:Protocol faster than DSL? by Anonymous Coward · · Score: 0

      Since you're so clever, how about posting some info on what fundamental limit is kicking in that prevents anything faster than DSL? Yeah, I thought not. Now who's the dumass?

    42. Re:Protocol faster than DSL? by Soporific · · Score: 1

      Isn't gig ether over copper too?

      ~S

    43. Re:Protocol faster than DSL? by BuckaBooBob · · Score: 1

      Its just bad use of language... The author should be sacked by fellow journalists... Its mixing context of meanings in a horrid way... Its like walking up to someone and saying "Whats the Diffrence Between an orange?"

      But now what is going to happen is there will be a Billion wannabe's running about Prasing BIC-TCP cause its gonna make thier DSL connection 6,000 times faster.

      But really its a horrid statement they way it was made... and to be more true to the example used.. if you didn't know how fast 100kph was or 62 mph it would like saying 100 kph/62mph is like 35 Monika Lewinski's internships at the whitehouse :)

      --
      Who needs WiFi when we can have Packet Over Sheep! http://datacomm.org/PoS-InternetDraft.txt
    44. Re:Protocol faster than DSL? by robotoverflow · · Score: 2, Insightful

      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.

      --
      % mkdir :
      % ls -dF :
      :/
    45. Re:Protocol faster than DSL? by hattmoward · · Score: 3, Informative

      What? DSL is a set of similar standards that share two-wire copper and use T1 signalling. (DS1 is T1 signalling over 4 copper wires) It's a link-level protocol and is completely transparent outside the terminations (the modem and the DSLAM, if you will). Saying DSL layers over IP is like tunneling a modem call to a BBS over VOIP. Home DSL implementations function as ethernet bridges, and some include PPPoE for further authentication over Ethernet MACs. At first, I thought you confused UDP with DSL, it is the unreliable protocol that IP stacks provide, but in the second paragraph, you said it is error-free, which UDP is not.

    46. Re:Protocol faster than DSL? by pseudochaotic · · Score: 1

      Wait, you can perform calculations on a grapefruit? Let's see...At an optimistic clock speed of 4 ghz, that makes the grapefruit run at about 20 seconds per cycle.

      --
      And the l33t shall inherit the 34r7h.
    47. Re:Protocol faster than DSL? by drinkypoo · · Score: 1

      RFC 1323 (TCP Extensions for High Performance)

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    48. Re:Protocol faster than DSL? by Anonymous Coward · · Score: 0

      Ya know there's an Aliens quote I'm thinking of, but I can't bring myself to debase it and AC's everywhere by repeating it.

    49. Re:Protocol faster than DSL? by Cynikal · · Score: 1

      and thanks for appreciating my humor :)
      i usually get a troll mod for my attempts

    50. Re:Protocol faster than DSL? by Anonymous Coward · · Score: 0

      Yet Ethernet is 10, 100 or 1000 Mb over what? Copper you say?

    51. Re:Protocol faster than DSL? by Loualbano2 · · Score: 2, Informative

      You are thinking of RFC1483 (Multiprotocol Encapsulation over ATM Adaptation Layer 5) which is obsoleted by RFC2684

      1483 Bridged does have lower overhead than PPPoA or PPPoE, but it sends broadcasts down the wire, both IP and Ethernet type. Depending on your network this could waste more bandwidth than PPPoX. 1483 Routed solves this, but you need ot allocate more IP space to use it.

      It's all a horse a piece.

      ft

    52. Re:Protocol faster than DSL? by pyrrhonist · · Score: 2, Informative
      Uh, no.

      Internet Standard #1 (currently RFC-3600 - November 2003) lists TCP as being Standard #7, which is outlined in RFC-793. RFC-793 was published in September 1981. In other words, we are still using the 1981 edition of TCP. RFC-793 contains the following note from Jon Postel:

      This document is based on six earlier editions of the ARPA Internet Protocol
      Specification, and the present text draws heavily from them.
      In addition, the RFC index lists RFC-675 (December 1974) as, "The first detailed specification of TCP".

      Thus, Dr. Rhee is a little bit off in his assesment.

      --
      Show me on the doll where his noodly appendage touched you.
    53. Re:Protocol faster than DSL? by JudgeFurious · · Score: 2, Funny

      Yep, or as it popped into my mind "You've never heard of the Millenium Falcon? It's the ship that made the Kessel Run in less than 12 parsecs"

      --
      Appended to the end of comments you post. 120 chars.
    54. Re:Protocol faster than DSL? by Pieroxy · · Score: 1

      Yes, you are right. The earth is flat.

    55. Re:Protocol faster than DSL? by jovlinger · · Score: 1

      Does DSL's speed guarantee come historically directly from ATM? I seem to recall that ATM had QoS guarantees, and I was wondering whether the speed provisions of DSL (you always get your rated speed) were designed in on purpose, or were already there as an unintended bonus of the pre-existing phone networks?

    56. Re:Protocol faster than DSL? by Anonymous Coward · · Score: 0

      yep, so's 10GBaseCX-4.

    57. Re:Protocol faster than DSL? by obeythefist · · Score: 1

      "Grapefruit". Is that some kind of apple mac thing?

      --
      I am government man, come from the government. The government has sent me. -- G.I.R.
    58. Re:Protocol faster than DSL? by Anonymous Coward · · Score: 0

      Faster internet means smooth porn replay. Just like potholes means better sex.

    59. Re:Protocol faster than DSL? by TheOnlyCoolTim · · Score: 1

      I don't think you've ever bought DSL. You don't necessarily get your rated speed. They expressly add a disclaimer that speed is not guaranteed.

      Tim

      --
      Omnia vestra castrorum habetur nobis.
    60. Re:Protocol faster than DSL? by f0rt0r · · Score: 2, Informative

      There are 7 layers in the OSI model. The pair of copper wires ( phone line ) would be layer 1, the way the DSL model sends data ( there are different ways of modulating the data ) is layer 2, now layer 3 we finally start getting to the actual data, but not yet a protocol for exchanging it, but at least it is up to ATM ( IP over ATM? I think ) now, layer 4, we finally got some data exhange going on between peers, and I forget the rest ( 5,6,7 ). But I am assuming from the article their protocol is at the layer 4.

      Btw, the DOD ( Dept. of Defense ) model lumps laters 3 and 4 together as the it's layer 3. 3 is network ( IP ) , and 4 being transport ( TCP ). But you almost never see on of the without the other, so they are popularly called TCP/IP .

      --
      I can't afford a sig!
    61. Re:Protocol faster than DSL? by turgid · · Score: 1
      You're absolutely right. Reading between the lines, and with my basic knowledge of networking, it looks like they've invented a new protocol for high-bandwith networks (fat pipes) with much lower overhead than IP (much larger packets?), better error correction and better algorithms for determining the most efficient path through the network for delivering packets.

      I doubt very much it would be of any benefit on a 56k modem or half-megabit ADSL connection. When we all get gigabit links into our homes, it may come into its own.

    62. Re:Protocol faster than DSL? by sir_cello · · Score: 2, Informative

      If we're going to be pedantic:

      - the first version of the TCP specification appeared in 1973 (http://texts05.archive.org/0/texts/FirstPassDraft OfInternationalTransmissionProtocol);
      - subsequent versions were released between 1974 and 1979;
      - the final version of TCP/IP was published by DARPA in January 1980 by which time numerous implementations existed;
      - The Department of Defense standardisation recommendation was made in December 1978 and ratified in April 1980 (http://www.isi.edu/in-notes/ien/ien152.txt);
      - The ARPANET officially switched over from NCP to TCP/IP on 1st January 1983;

      If you want to know about congestion control, look at the work by Sally Floyd - it's her specialty and she sits on IETF now days. Since the original VJ work, many others have investigated various types of changes to TCP's congestion avoidance and control mechanisms: it was a very active area of investigation.

    63. Re:Protocol faster than DSL? by Anonymous Coward · · Score: 0

      Or a sailing boat that goes 6,000 times faster than the wind!

    64. Re:Protocol faster than DSL? by SeXy_Red · · Score: 1
      What is BIC trying to fix? It certainly isn't "the internet" as most links, on average, run at a fraction of their available bandwidth. TCP can fill up more bandwidth than most people can aford.


      Your not looking at the big picture, sure right now most connections are not limited by TCP/IP. But what about in 5 years? 10 years? 20? If the average connection speed is indeed doubling every year, how long do you think it will take for most users to hit the TCP/IP "Wall"?

      --

      This sig was generated by a barrel of trained kittens for SeXy_Red (550409).

    65. Re:Protocol faster than DSL? by dreamchaser · · Score: 1

      They explained that one away in the later books. Making the Kessel Run in that short a distance meant skirting dangerously close to a gravitational anomaly. Most people had to take a much longer route.

    66. Re:Protocol faster than DSL? by Anonymous Coward · · Score: 0

      "kph"?

      Try "km/h".

    67. Re:Protocol faster than DSL? by Octorian · · Score: 2, Informative

      First of all, the OSI model needs to be taken with a grain of salt. It does not directly map to the way things really work. Furthermore, there is flexibility allowed for layers of indirection.

      However, from the host's view down, TCP, UDP, or BIC-TCP is layer 4, IP is layer 3, and all that DSL/ATM/etc. stuff fits under the guise of Layer 2 and below. (of course with layers of indirection, you can simulate the ATM cloud over IP /w MPLS as well, but that is all transparent beyond the provider network)

    68. Re:Protocol faster than DSL? by omarques · · Score: 0

      I'm brazilian, and "Pinto" is the portuguese word for dick, so everytime I see a reference to this car, is kinda funny.

      I wonder why Ford didn't ever released this car here...

    69. Re:Protocol faster than DSL? by Lennie · · Score: 2, Insightful

      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.

      --
      New things are always on the horizon
    70. Re:Protocol faster than DSL? by RichardX · · Score: 1

      Its like walking up to someone and saying "Whats the Diffrence Between an orange?"

      One of it's segments is both the same.
      Neeeeext.

      --
      Curiosity was framed. Ignorance killed the cat.
    71. Re:Protocol faster than DSL? by RichardX · · Score: 1

      Put any car on a racetrack filled with pot-holes and the car won't be able to get anywhere very quickly, will it?

      Not a fan of the World Rally Championship, then?

      --
      Curiosity was framed. Ignorance killed the cat.
    72. Re:Protocol faster than DSL? by GoRK · · Score: 1

      I have these tires on my car. They are fscking sxweet!!!!!

    73. Re:Protocol faster than DSL? by ZHaDoom · · Score: 0

      The Millenium Falcon is the ship that made castle run in less than twelve parsecs, she's fast enough for your dsl.

      --
      War isn't about who's right. It's about who's left.
    74. Re:Protocol faster than DSL? by f0rt0r · · Score: 1

      Good point. :)

      --
      I can't afford a sig!
    75. Re:Protocol faster than DSL? by wampus · · Score: 1

      I just thought I'd add that you NEED an off center racing stripe and at least 6 other stickers to really take advantage of these tires.

    76. Re:Protocol faster than DSL? by GoRK · · Score: 1

      having an exhaust pipe that you can fit a soccer ball inside doesn't hurt either

    77. Re:Protocol faster than DSL? by DR+SoB · · Score: 1

      FTP over TCP/IP? Hmmmm, silly me, I thought FTP was part of the TCP/IP protocol.. I guess you would call TCP over IP? (say wha?) but you said DSL was a "a datagram-based protocol" I assume that means it's UDP ("User Datagram Protocol")? OHhhhhhHHHhH, you mean it's a "Packet Driven" protocol... ok.. thanks for the free education.. I guess I can throw out my TCP for Dummies book now..

      --
      Mod +5 Drunk
    78. Re:Protocol faster than DSL? by siphi · · Score: 0

      Sorry to sound stupid, but wtf is a POTS line?? When you bang a pot and the other pot revieves the signal by resonance????

      --
      Sig (appended to the end of comments you post, 120 chars)
    79. Re:Protocol faster than DSL? by digitalsurgeon · · Score: 1

      Pardon my ignorance guys, but does POTS mean Plain Old Telephone System ?

    80. Re:Protocol faster than DSL? by jovlinger · · Score: 1

      true, (I do, so I tend to forget); however, you always get the same speed, even though it may not be the one you thought you bought.

    81. Re:Protocol faster than DSL? by Anonymous Coward · · Score: 0

      you should know...

      you have quite a few things fitted in YOUR "exhaust pipe"....

      ~GoAT~

  3. oops by poot_rootbeer · · Score: 4, Funny


    Looks like the server just got Slashdotter 6,000 times faster than normal.

    1. Re:oops by vensonOnSlashdot · · Score: 0

      You can say they got BIC-SLAC'ed by /.

  4. New Protocol???!!!! by ptelligence · · Score: 5, Funny

    Use it to host your blog server..immediately? You've been slashdotted.

  5. Propagation delays by trompete · · Score: 4, Interesting

    Too bad they can't change the speed of light. 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.

    1. Re:Propagation delays by jimbosworldorg · · Score: 5, Informative

      An awful lot of propagation delay tends to be equipment-internal rather than wire-length. Until you start talking about REALLY long distances like using satellite-based networking, anyway.

      --

      Coming soon to Slashdot: meta-meta-moderation!

    2. Re:Propagation delays by trompete · · Score: 1

      One that pisses me off is how the networks aren't bridged well. My ping to Ohio from Minneapolis was 40 MS with Comcast, and now it is 120 MS with RoadRunner. My packets are pretty tired by the time they get to San Jose and then back to Ohio. What sort of delays are you talking about inside of the devices? Most devices can start pass-through once they have the destination address out of the header. This is not true for store-and-forward devices though :(.

    3. Re:Propagation delays by Anonymous Coward · · Score: 1, Interesting

      That's bogus. I live down here in Australia - the first country outside the US to join the 'net. Equipment delays between my home router and google.com's front end come to around 30ms. The delay going through fibre adds another 120ms to that figure. Using satellite adds another 400ms or more, again. (can't remember for sure, it's been a long time since I used a satellite link...)

    4. Re:Propagation delays by jimbosworldorg · · Score: 5, Informative
      Every hop adds several milliseconds for processing time - and considerably more if the router in question is getting hit at the upper limit of its rated throughput (and thus having to buffer-and-wait instead of immediately routing packets).

      Speed-of-light is 186,000,000 meters per second - from (Cincinnatti) Ohio to Minneapolis is roughly 1600km by highway, which would leave you with a wire-speed delay of only 16ms round-trip.

      The extra 34ms you get on a well routed network generally tends to be time spent getting passed through intermediate routers along the way. Each router *does* add a noticeable amount of delay all of its own, apart from wire delay.

      --

      Coming soon to Slashdot: meta-meta-moderation!

    5. Re:Propagation delays by scowling · · Score: 1

      I suspect that Canada joined the Net long before Australia did.

      --
      www.kitchengeek.com -- Nosh for
    6. Re:Propagation delays by trompete · · Score: 1

      Isn't it 186,200 MILES per second or 300,000,000 KM per second. Just checking.

    7. Re:Propagation delays by trompete · · Score: 2, Informative

      Way too many zeros on the KMs :) --> 300,000 KM/s

    8. Re:Propagation delays by jimbosworldorg · · Score: 2, Funny

      You are correct sir. Thankfully, your correction of my own dumb mistake only made my original point more valid, so ... um ... LOOK! A BEAR!

      --

      Coming soon to Slashdot: meta-meta-moderation!

    9. Re:Propagation delays by jimbosworldorg · · Score: 1
      uh, well, now that trompete points it out, your leading 3 is correct, not my leading 1.86; but my 9 significant figures is correct, not your 12.

      math is hard. :)

      --

      Coming soon to Slashdot: meta-meta-moderation!

    10. Re:Propagation delays by Quo_R · · Score: 1

      You do realize that Light can travel 30.000 kilometres in 100ms while the point farthest from you on the earth's surface is only 20.000 km away, right?

    11. Re:Propagation delays by Cheo · · Score: 1

      the speed of light = 299,792,458 meters/second

    12. Re:Propagation delays by trompete · · Score: 1

      Now get me a direct link to there, and we'll be set :)

    13. Re:Propagation delays by Percy_Blakeney · · Score: 2, Insightful
      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.

    14. Re:Propagation delays by ffub · · Score: 2, Insightful

      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.

    15. Re:Propagation delays by Frennzy · · Score: 2, Informative

      That's also the speed of light in a vacuum.

      Electrical and optical signals travelling down copper or FO pathways (as well as microwaves through the air) have a reduced propagation speed. A good rule of thumb is about .7c.

    16. Re:Propagation delays by An+Onerous+Coward · · Score: 1

      I hear that some interesting research is being done to route fiber optic signals without making the light-electric-light conversion at all. I'm fuzzy on how this would be accomplished (I remember something about reflective/refractive balls of liquid, kind of along the lines of inkjet printing technology) but that would certainly get your ping times way down.

      --

      You want the truthiness? You can't handle the truthiness!

    17. Re:Propagation delays by SoSueMe · · Score: 1

      This should be close enough.
      Hope it helps.

    18. Re:Propagation delays by SETIGuy · · Score: 5, Funny
      My ping to Ohio from Minneapolis was 40 MS with Comcast, and now it is 120 MS with RoadRunner.


      40 Megasiemens? Don't you also need to know the capacitance and inductance of the connection in order to figure out the ping time from that?

      % units

      You have: 40 MS
      You want: years
      conformability error
      40000000 A^2 s^3 / kg m^2
      31556926 s
    19. Re:Propagation delays by Anonymous Coward · · Score: 0

      Routers don't add a significant delay... back in 1992 you were right... but routers used by Service Providers today route by only adding microseconds of delay. Pretty insignificant.

      Even if Point A to Point B is 300 miles, the actual fiber route may be 500 miles.

    20. Re:Propagation delays by Alakaboo · · Score: 1

      What?? Speed of light is 186,000 MILES per second, or 300,000,000 meters per second. But electrons propogate at about 2/3 the speed of light in copper, so you get 1.6e6 m / 2e8 m/s or 32ms (64ms round-trip).

      So I'm going to assume I was just trolled...

    21. Re:Propagation delays by Anonymous Coward · · Score: 0

      Perhaps "they" CAN. if the speed of light is determined by the substance it travels through (isn't this a key concept of diffraction?), then the possibility of a substance that light travels through FASTER than C(void) MAY exist. *shrug*

    22. Re:Propagation delays by hta · · Score: 1

      actually a lot of the delay IS speed-of-light.
      I once wrote a program that sent out small packets and big packets and looked at the difference in propagation times - you could get a reasonable first-order-of-magnitude guess at the actual bitrate of the links from the variation in echo times (which is due to how long it takes to clock the packet onto the wire), and once that's out of the way, you can try to match up the delay with the distance between the sites. Turns out that for intercontinental, you have pretty good luck guessing at the length of the wire between cities....
      (no, it was never released, and I don't have the code any more - three jobs ago, and in an age where 2 Mbits/sec was a high speed link....)

    23. Re:Propagation delays by fbjon · · Score: 1
      Now this is really OT, but following that link, and then further: related articles -> north pole, brings me to a crazy quote..
      "Since the earth's rotation takes place once every 24 hours,"
      Wow! Imagine that.. That's some kickass rotation!
      --
      True confidence comes not from realising you are as good as your peers, but that your peers are as bad as you are.
    24. Re:Propagation delays by Anonymous Coward · · Score: 0

      ..and its not the electrons that propagate, they move with speeds around cms/second.

    25. Re:Propagation delays by Quo_R · · Score: 1

      http://en.wikipedia.org/wiki/Speed_of_light Add that to the about.com link in the other reply and do the math...

    26. Re:Propagation delays by Kynde · · Score: 1

      But electrons propogate at about 2/3 the speed of light in copper

      Some electrons you've got there, man. Our local electrons can't even keep up with sound waves in copper, but luckily our electromagnetic fields are fast enough for online gaming.

      --
      1 Earth is warming, 2 It's us, 3 it's royally bad, 4 we need to take action NOW
  6. hmm by krisp · · Score: 5, Interesting

    This seems misleading. The artical says:
    "What takes TCP two hours to determine, BIC can do in less than one second,"

    Which looks to me like it can figure out the maximum bandwidth of a channel in a fraction of the time it generally takes TCP to do it, so as soon as you start transmitting at 100mbit you are using the entire pipe. Sure, its 6000 times faster than DSL but its not when it is used over the same DSL pipe. This is for getting data accross faster when you have massive bandwidth, not for bringing broadband into homes.

    1. Re:hmm by Anonymous Coward · · Score: 0

      2 hours.. lol

    2. Re:hmm by BW_Nuprin · · Score: 1

      Is that why downloads generally start off slow and speed up over the course of several minutes? I'd always just figured that was due to bps calculation sucking like it did back in the BBS days... but I guess I never really thought about it very much. Then again, I don't know much about how TCP/IP works... network programming always gives me such a headache.

  7. ob. simpsons ref. by ejaw5 · · Score: 4, Funny

    Nerd: I've developed a program that downloads porn from the interet a million times faster than normal

    Marge: Who would need that much porn

    Homer: [drools]...oohhh..1 million times faster..

    --

    $cat /dev/random > Sig
    1. Re:ob. simpsons ref. by Anonymous Coward · · Score: 0

      Marge: Who would need that much porn

      Obviously, the 5 richest kings of Europe.

    2. Re:ob. simpsons ref. by Anonymous Coward · · Score: 0

      The trick is that all the porn is composed of fractal shapes.

  8. CS by YanceyAI · · Score: 1
    Many national and international computing labs are now involved in large-scale scientific studies of nuclear and high-energy physics, astronomy, geology and meteorology. Typically, Rhee said, "Data are collected at a remote location and need to be shipped to labs where scientists can perform analyses and create high-performance visualizations of the data."

    They forgot to mention Steam.

    --
    Can I bum a sig?
  9. Re:please don't do this. by apoplectic · · Score: 2, Interesting

    Don't worry. It won't be long before you have to suffer through a 30 minute streaming infomercial before getting to your desired bloated web page.

  10. Yikes! How can a home user tell? by BenSpinSpace · · Score: 2, Insightful

    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.

  11. Bottle Necks by pholower · · Score: 2, Informative

    It doesn't matter what the bandwidth of your pipe coming in is. It only matters what the connection of the other servers and switches is in the "internet cloud" At a rate like that, I would also wonder if ANY of the infrastructure we have in place would be able to keep up. Seems like something that wouldn't happen for decades.

    --
    -- johntracy.com, because everybody else is wrong.
    1. Re:Bottle Necks by Anonymous Coward · · Score: 0
      It doesn't matter what the bandwidth of your pipe coming in is

      only guys with small pipes say that...
  12. Ack... by adamofgreyskull · · Score: 1, Redundant

    Someone needs a clue-bashing with the OSI model. A new internet protocol that's faster than DSL?? So...it negates the use a physical transmission system..or...what?

    1. Re:Ack... by Anonymous Coward · · Score: 0

      Yes.. carrier pigeons with acme rockets on their backs.

    2. Re:Ack... by len_harms · · Score: 1

      Is this like the Kessel run?

    3. Re:Ack... by Rallion · · Score: 2, Funny

      No. Unlike this, the Kessel Run can be explained in a way that makes sense.

  13. Great measurement by TheOnlyCoolTim · · Score: 3, Funny

    There's 640 kbps DSL and there's 3 Mbps DSL...

    I want it in LOC/sec.

    Tim

    --
    Omnia vestra castrorum habetur nobis.
    1. Re:Great measurement by Zone-MR · · Score: 2, Funny

      LOCs/second rely partially on SI units. Personally I prefer deciLOCs/fortnight.

    2. Re:Great measurement by Anonymous Coward · · Score: 0

      I'm in Japan and here we have 40Mbps ADSL.

      1.5, 8, 12, 24, 40Mbps are all available here.

      6000 times faster than 40Mbps...240Gbps! Man, and I thought my 100Mbps fibre line was fast.

    3. Re:Great measurement by Anonymous Coward · · Score: 0

      In imperial units it's 18 Libraries of Congress in 3 Volkswagens, driving the length of 6 Football Fields.

  14. Misleading & LAME! by Anonymous Coward · · Score: 0

    LAME! Anyone with half a brain knows that backoff kills TCP throuput. I wanted a new high-speed alternative to DSL and all I got was another lame TCP knock-off. What is this, something like the 12th new TCP?

  15. mirror by Anonymous Coward · · Score: 5, Informative

    Slowing down so here it is...

    New protocol could speed Internet significantly
    Posted on Monday, March 15 @ 14:04:08 EST by bjs

    Researchers in North Carolina have developed a data transfer protocol for the Internet that makes today's high-speed Digital Subscriber Line (DSL) connections seem lethargic. The protocol is named BIC-TCP, which stands for Binary Increase Congestion Transmission Control Protocol. In a recent comparative study run by the Stanford Linear Accelerator Center (SLAC), BIC consistently topped the rankings in a set of experiments that determined its stability, scalability and fairness in comparison with other protocols. The study tested six other protocols developed by researchers from schools around the world, including the California Institute of Technology and the University College of London. BIC can reportedly achieve speeds roughly 6,000 times that of DSL and 150,000 times that of current modems.

    From North Carolina State University:

    NC State Scientists Develop Breakthrough Internet Protocol

    Researchers in North Carolina State University's Department of Computer Science have developed a new data transfer protocol for the Internet that makes today's high-speed Digital Subscriber Line (DSL) connections seem lethargic.

    The protocol is named BIC-TCP, which stands for Binary Increase Congestion Transmission Control Protocol. In a recent comparative study run by the Stanford Linear Accelerator Center (SLAC), BIC consistently topped the rankings in a set of experiments that determined its stability, scalability and fairness in comparison with other protocols. The study tested six other protocols developed by researchers from schools around the world, including the California Institute of Technology and the University College of London.

    Dr. Injong Rhee, associate professor of computer science, said BIC can achieve speeds roughly 6,000 times that of DSL and 150,000 times that of current modems. While this might translate into music downloads in the blink of an eye, the true value of such a super-powered protocol is a real eye-opener.

    Rhee and NC State colleagues Dr. Khaled Harfoush, assistant professor of computer science, and Lisong Xu, postdoctoral student, presented a paper on their findings in Hong Kong at Infocom 2004, the 23rd meeting of the Institution of Electrical and Electronics Engineers Communications Society, on Thursday, March 11.

    Many national and international computing labs are now involved in large-scale scientific studies of nuclear and high-energy physics, astronomy, geology and meteorology. Typically, Rhee said, "Data are collected at a remote location and need to be shipped to labs where scientists can perform analyses and create high-performance visualizations of the data." Visualizations might include satellite images or climate models used in weather predictions. Receiving the data and sharing the results can lead to massive congestion of current networks, even on the newest wide-area high-speed networks such as ESNet (Energy Sciences Network), which was created by the U.S. Department of Energy specifically for these types of scientific collaborations.

    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. "Now we are trying to apply it to networks that have several orders of magnitude more available bandwidth." Essentially, we're using an eyedropper to fill a water main. BIC, on the other hand, would open the floodgate.

    Along with postdoctoral student Xu, Rhee has been working on developing BIC for the past year, although Rhee said he has been researching network congestion solutions for at least a decade. The key to BIC's speed is that it uses a binary search approach - a fairly common way to search databases - that allows for rapid detection of maximum network capacities with minimal loss of information. "What takes TCP two hours to determine, BIC can do in les

    1. Re:mirror by Krov · · Score: 1
      "What takes TCP two hours to determine, BIC can do in less than one second," Rhee said.
      I bet that's the source of the number 6000. Two hours is 7200 seconds, so a conservative estimate would be that BIC is "about 6000 times faster" than TCP at detecting network capacities. The rest is hopefully the fault of the reporter...
  16. The site is already very unhappy. by trompete · · Score: 0, Redundant

    Researchers in North Carolina have developed a data transfer protocol for the Internet that makes today's high-speed Digital Subscriber Line (DSL) connections seem lethargic. The protocol is named BIC-TCP, which stands for Binary Increase Congestion Transmission Control Protocol. In a recent comparative study run by the Stanford Linear Accelerator Center (SLAC), BIC consistently topped the rankings in a set of experiments that determined its stability, scalability and fairness in comparison with other protocols. The study tested six other protocols developed by researchers from schools around the world, including the California Institute of Technology and the University College of London. BIC can reportedly achieve speeds roughly 6,000 times that of DSL and 150,000 times that of current modems.

    From North Carolina State University:

    NC State Scientists Develop Breakthrough Internet Protocol

    Researchers in North Carolina State University's Department of Computer Science have developed a new data transfer protocol for the Internet that makes today's high-speed Digital Subscriber Line (DSL) connections seem lethargic.

    The protocol is named BIC-TCP, which stands for Binary Increase Congestion Transmission Control Protocol. In a recent comparative study run by the Stanford Linear Accelerator Center (SLAC), BIC consistently topped the rankings in a set of experiments that determined its stability, scalability and fairness in comparison with other protocols. The study tested six other protocols developed by researchers from schools around the world, including the California Institute of Technology and the University College of London.

    Dr. Injong Rhee, associate professor of computer science, said BIC can achieve speeds roughly 6,000 times that of DSL and 150,000 times that of current modems. While this might translate into music downloads in the blink of an eye, the true value of such a super-powered protocol is a real eye-opener.

    Rhee and NC State colleagues Dr. Khaled Harfoush, assistant professor of computer science, and Lisong Xu, postdoctoral student, presented a paper on their findings in Hong Kong at Infocom 2004, the 23rd meeting of the Institution of Electrical and Electronics Engineers Communications Society, on Thursday, March 11.

    Many national and international computing labs are now involved in large-scale scientific studies of nuclear and high-energy physics, astronomy, geology and meteorology. Typically, Rhee said, "Data are collected at a remote location and need to be shipped to labs where scientists can perform analyses and create high-performance visualizations of the data." Visualizations might include satellite images or climate models used in weather predictions. Receiving the data and sharing the results can lead to massive congestion of current networks, even on the newest wide-area high-speed networks such as ESNet (Energy Sciences Network), which was created by the U.S. Department of Energy specifically for these types of scientific collaborations.

    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. "Now we are trying to apply it to networks that have several orders of magnitude more available bandwidth." Essentially, we're using an eyedropper to fill a water main. BIC, on the other hand, would open the floodgate.

    Along with postdoctoral student Xu, Rhee has been working on developing BIC for the past year, although Rhee said he has been researching network congestion solutions for at least a decade. The key to BIC's speed is that it uses a binary search approach - a fairly common way to search databases - that allows for rapid detection of maximum network capacities with minimal loss of information. "What takes TCP two hours to determine, BIC can do in less than one second," Rhee said. The greatest challenge for the new protocol, he added, was to fill the pipe fast without starving out other protoco

    1. Re:The site is already very unhappy. by The+Happy+Camper · · Score: 1

      They may have the ultamate bandwidth, but their pop-up provider's ad server just got /.'ed

  17. Summary: BIC-TCP is an efficient TCP successor by ClayJar · · Score: 4, Informative

    To quote the part that says what the article is actually about:

    The key to BIC's speed is that it uses a binary search approach - a fairly common way to search databases - that allows for rapid detection of maximum network capacities with minimal loss of information. "What takes TCP two hours to determine, BIC can do in less than one second," Rhee said.
    1. Re:Summary: BIC-TCP is an efficient TCP successor by zalas · · Score: 5, Insightful

      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.

    2. Re:Summary: BIC-TCP is an efficient TCP successor by ezzzD55J · · Score: 1
      That, and BIC can adjust its window size faster, allowing bandwidth utilisation in a fast connection to reach optimum faster..

      Not that I believe TCP is that bad to begin with..

  18. Fastest Slashdot by ThisNukes4u · · Score: 1

    That is one of the fastest slashdottings i've seen in a while. The technology sound's good, if only they can keep it cheap and readily available.

    --
    thisnukes4u.net
    1. Re:Fastest Slashdot by glass_window · · Score: 1

      You might say they were slashdotted 6000 times that of a normal slashdotting.

  19. protcol and hardware by ccozan · · Score: 0, Redundant

    isn't DSL a hardware technology ( Layer 1 ) whereas a protocol ( TCP, or their invention BIC-TCP) is a layer 3???

    Please compare apples with apples and oranges with oranges.

    The article makes me laugh, really....

    Costin

    1. Re:protcol and hardware by ccozan · · Score: 1

      correction, DSL is a Layer 2 and TCP is a Layer 4...

    2. Re:protcol and hardware by SultanCemil · · Score: 1

      TCP is actually layer 4. IP would be layer 3. And yes, the comparison is ridiculous.

      --
      Cemil.
  20. Comparing apples and oranges by EatenByAGrue · · Score: 2, Redundant

    A new protocol that's 150,000 times the speed of current modems? Uh...I think the reviewer got a little mixed up here. There's the max theoretical speed of the transmission line, and then there's the speed at which the protocol can transmit over that line. While I'm sure it can make modems faster by transmitting more bytes, its not going to make modems 150,000 times faster.

  21. I created... by Anonymous Coward · · Score: 0

    A protocol that hums along at 1,000,000 times DSL speed.

    I took the physical spec of DSL and added 1,000,000 lines.

  22. Apples and Oranges? by Ars-Fartsica · · Score: 5, Insightful
    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.

  23. Eh? by Jeffrey+Baker · · Score: 0, Redundant

    And a ferrari is larger than an orange. WTF is up with this headline? A protocol is faster than a signalling method. Great. To enhance the uselessness, the protocol's speed is measured in multiples of something vague, rather than megabits per second. Nothing turns up for "BIC-TCP" on CiteSeer, so we'll just have to guess until an actual journalist picks up the story.

  24. Pesky physical layer.. by newnam · · Score: 1

    Sure.. if you get rid of those pesky lower layers, data just zooms along.

  25. Mirror by Anonymous Coward · · Score: 0
  26. Oh, crap! by MattC413 · · Score: 1

    6,000 times the speed of DSL? Wow.. if only places came up with content 6,000 faster..

    Quick! Someone alert the porn industry!

    BATTLESTATIONS! :)

  27. Cheap Bandwidth by Un0r1g1nal · · Score: 0, Troll

    Bandwidth in reality is alreay cheap, there are protocols that are being used by the likes of cisco that make a 56k modem faster than broadband. Why is it not being implimented? The broadband companies need to make the money back from the investment in their infrastructure. Why upgrade to a 512k broadband connection if your modem can go faster? no need. It will be interesting to see when these actual protocols hit the market.

    In answer to above the DSL protocol is the way in which your line is utalised to incorprate digital signals down a standard telephone wire. see here for more info

    --
    If at first you DON'T succeed, Skydiving is NOT for YOU!!
    1. Re:Cheap Bandwidth by Anonymous Coward · · Score: 0

      Link Please?

      Uh, Shannon's law?

      Uh, phone lines are digitized @ 64 kbps?

      Uh, troll?

    2. Re:Cheap Bandwidth by Tailhook · · Score: 2, Funny

      there are protocols that are being used by the likes of cisco that make a 56k modem faster than broadband. Why is it not being implimented? The broadband companies need to make the money back from the investment in their infrastructure.

      "Detroit" has a 100mpg carburetor that oil companies suppress to maintain price.

      "Alternative" medicine is rejected by "Western" medicine to preserve medical monopolies.

      Solar power if so cheap and efficient that it can easily provide for all our energy needs, but is prevented from being adopted to maintain "power company" profits.

      Unions are the source of all progress but have been ruined by business.

      NASA is an aerospace subsidy and ignores scientists to fund "big budget" projects like the Space Shuttle.

      America hoards food that could eliminate starvation planet wide.

      The media is controlled by any one of; corporate interests, right wing Christians or left wing socialists.

      The Cold War was created to justify the "Military Industrial Complex."

      Power lines, cell phones and chlorine are causing a cancer epidemic. ...and now Cisco has a "protocol" that makes a 56k modem faster than "broadband."

      --
      Maw! Fire up the karma burner!
    3. Re:Cheap Bandwidth by alannon · · Score: 4, Informative

      You appear to be rather confused.
      Modems that plug into your regular telephone line send a signal over a POTS (Plain-Old Telephone Service) phone line. This signal first goes to your telcos closest routing box, then to your telcos closest branch office. From there it gets routed to wherever your phone call was made to, etc... The technology used to route these signals is limited to a maximum THEORETICAL capacity of less than 64kbps because certain (or all) legs of the telephone network are analogue, not digital. That 'theoretical' rate is based on how much noise a typical telephone call has in it. There is simply no way to pass a denser signal through the line than that, according to our understandings of physics and math.
      The only similarity that DSL has to POTS internet connections is that the physical wires to your house are compatible and that (sometimes) the two technologies can be used over a single pair of them. Once the signal of a DSL line gets to its very first junction, it has nothing in common with your phone line any longer. It gets sent to a DSLAM bank at your nearest telco site, then sent into the larger regional DSL network and then finally routed out into the internet at large.
      What this means is, basically, is 1) there is a good reason why modem speeds haven't increased at all since 56kbps modems came out -- it's physically impossible for them to go faster. 2) DSL technology is transitory -- It only exists because people currently have wires from their telco already coming into their homes. I predict that slowly, over the next 10 years, we'll see telecommunications turn on its head. Instead of internet service being delivered over phone lines, we will have phone service delivered over internet connections. These lines may take the form of twisted-pair wires as is used in DSL, multiple twisted-pair wire groups as are used in ethernet, coaxial wires currently used in cable-tv/cable-modem service, or fiber-optical cables. The only thing I can guarantee is that they won't be routed through the telephone network before being passed into the internet.

    4. Re:Cheap Bandwidth by Valdrax · · Score: 1

      America hoards food that could eliminate starvation planet wide.

      Worse, we destroy food that could eliminate starvation planet-wide just to keep the prices artificially high so that farmers can recoup their investment and not go broke. The problem has never been production but the impossibility of getting it to all of those people thanks to their f'ed up governments and our desire to actually make money from doing so. Of course the irony is that when we DO dump food aid on other countries, it outcompetes the local farmers and drives them into poverty. It's a lose-lose situation thanks to unequal production capacity and a lack of assured cooperation.

      --
      If it's for-profit but free, you're not the customer -- you're the product (e.g., the Slashdot Beta's "audience").
    5. Re:Cheap Bandwidth by jsebrech · · Score: 1

      It's true that the modem is limited to current speeds because of the way the phone network is designed, but this has nothing to do with physical ability of the wires to carry data, but rather of how pots hardware makes use of them. A phone signal is repeated and multiplexed, and no more bandwidth than those 64kbit (actually, slightly less than that) is guaranteed to be available over any single phone circuit. The physical copper wires have huge bandwidth ability compared to that, and that's what dsl takes advantage of. DSL uses the full bandwidth of the physical wire, but that means that the signal can't be repeated by regular POTS hardware (which is why the phone network had to be upgraded locally for it to become available). Old-style modems are designed to use the maximum of what repeaters will allow a phone conversation to carry information-wise, and so they make it possible to dial into anywhere in the world, as long as the phone network connects the two points.

      Noise tends to limit the available bandwidth of a phone circuit even more (because noise is information and so takes up bandwidth that could be used by useful information). So a noisy circuit will make a modem fall back to even lower speeds. But even on an absolutely (entirely digital) phone circuit, there is still no more bandwidth available than 64k.

    6. Re:Cheap Bandwidth by jsebrech · · Score: 1

      Damn that not previewing habit I have. I meant "absolutely noiseless" instead of just "absolutely".

    7. Re:Cheap Bandwidth by Anonymous Coward · · Score: 0
      "Detroit" has a 100mpg carburetor that oil companies suppress to maintain price.

      I've witnessed these things in action. They exist. Honestly, this is one case where the conspiracy theory is probably correct -- people who figure out how to do this traditionally end up dead.

  28. DSL speed vs IP speed by DaveRobb · · Score: 5, Insightful

    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.

    1. Re:DSL speed vs IP speed by gsabin · · Score: 1

      Are you sure BIC-TCP is in network layer? I assume that they are not messing with the Network Layer (IP) and BIC-TCP replaces TCP in the transport layer. However, I did not read the paper so I could be wrong. Especially in assuming that BIC-TCP runs over IP

    2. Re:DSL speed vs IP speed by Anonymous Coward · · Score: 2, Informative

      Well, if you would RTFA, then you would see that the point of the BIC protocol is to decrease the bottlenecks created by TCP on speciallized high speed data transmission networks (not your DSL line) such as those used by universities and other research institutions. Even if you have a bundle of fiber to your house with an optical computer your throughput will still be limited by TCP congestion.

      The comparison to DSL and modems is meant to demonstrate to people with no specialized knowledge of network architecture the speed increase gained from BIS. That would be your average layperson. So your current GigaBit network will not longer be slowed by TCP.

    3. Re:DSL speed vs IP speed by Anonymous Coward · · Score: 0

      No it does not become faster. But the actual paper mentions that the mechanism behaves like "vanilla" TCP under slow links (satisfying the "backwards-compatible" requirement.

      To the people that say TCP is 1970s technology I have this to say:
      The standard for TCP implementation went through the IETF and was ratified in 1981 (RFC 793).

      The final touches for modern TCP became official in 1997 in RFC 2001 (although they had crept in vendor implementations way before then).

      TCP research on all levels is very active today especially for lossy wireless links and high speed links. The paper is well written but I would like to see a comparison of their method with the recently proposed H-TCP from the Hamilton institute which is very promising as well (a hint to researchers in high speed networking).

      Ok one more "fun" fact. In literature you might notice TCP being called TCP Reno or Tahoe or some other Nevada-derived term. It is so, because BSD 4.3-Reno contained a full free implementation of TCP which was widely used for research in academia. The term was used for the distribution because it was an interim release and the adventurous were taking a "gamble" trying it out. This trend follows us to this day... check out TCP Vegas mentioned in the paper....

      (If you need more info search for the RFCs and see for yourselves...)

    4. Re:DSL speed vs IP speed by DaveRobb · · Score: 1

      You're right, it should be transport layer. I obviously require more coffee. :)

    5. Re:DSL speed vs IP speed by DaveRobb · · Score: 1

      Correct, it won't be slowed by TCP. But that doesn't make it "6000 times faster than DSL", because (at least for my DSL connection), that would give me a 36Gbit link. Where do I sign up? :)

      Comparing BIC-TCP directly to DSL is misleading.

    6. Re:DSL speed vs IP speed by 680x0 · · Score: 1
      Good summary. But I have to correct you on one minor point:
      DSL is a link-layer protocol.
      Actually, it's not link layer (layer 2 in OSI, which separates a bit stream into units called "frames", and identfies frame types, addressing, etc.). It's physical layer (using voltages to encode bits), in the case of DSL, using frequency-domain multiplexing to encode 3 different links (inbound data, outbound data, voice) onto the same wires.

      Usually DSL uses PPP and Ethernet (PPPoE) or PPP and ATM (PPPoA) as its link layers.

  29. Warrent some (lots of) explanation by lingqi · · Score: 5, Informative

    What they mean is that current TCP protocol becomes a bottleneck at high bandwidth applications, so a new protocol is designed that would be efficient up to ~6000xDSL speed (just a pot-shot guess, up to 9Gb/S?). It has nothing to do with pushing data down the POTS line, just that if one day you had a fat pipe to your house, this new protocol would make use of it properly unlike today's TCP.

    It's a stupid comparison, but I guess they expect people to not have an idea what 9Gb/S is...

    --

    My life in the land of the rising sun.

    1. Re:Warrent some (lots of) explanation by John+Courtland · · Score: 1

      Now, I'm no protocol researcher but can't the TCP/IP stack change the MTU and MRU to adjust the packet size for the connection speed/quality?

      --
      Slashdot is proof that Sturgeon's Law applies to mankind.
    2. Re:Warrent some (lots of) explanation by starm_ · · Score: 4, Informative

      I have downloaded at 400kB/s on my computer.

      6000 times that is 2400MB/s

      This is faster that conventional RAM. A PC would not be able to accept the data at that speed fast enough to store it in RAM!

      The headline is obviously sensationalism.

      There exist fast optical cariers but they serve purposes that are very different to what DSL lines are meant to be. These are the kind of line that connects cities together and are not to be compared to DSL.

    3. Re:Warrent some (lots of) explanation by 680x0 · · Score: 4, Informative
      Yes, you can adjust the max. receive (MRU) and transmit (MTU) packet sizes. The MRU isn't adjusted, usually, just accept as big a packet as you can. The MTU can be adjusted manually (by the sysadmin), or automatically (PMTUD - path MTU discovery).

      However, adjusting the MTU has little to do with speed, as the Window Size (how much data can be transmitted before being acknowledged by the far end) is specified in number of bytes (in TCP). I suppose it could have some effect on speed, as when you send a packet that exceeds the MTU, it gets "segmented" into multiple IP packets, each with its own packet header overhead (and if any get lost, the whole bunch have to get retransmitted).

      What this new protocol deals with, however, is dynamically varying the window-size. Current TCP does that, but apparently not in as efficient a manner as this.

      So all this "x thousand times faster than DSL" is just complete bullshit. You'll never get any faster speeds than the slowest link between point A and point B. This new protocol simply tries to use the Y/bits-per-second available more efficiently. And you won't notice the inefficiency of the current TCP at speeds most DSL/cable/dialup users have available.

      Some tech journalists are just idiots.

    4. Re:Warrent some (lots of) explanation by AK+Marc · · Score: 2, Informative

      However, adjusting the MTU has little to do with speed,

      It affects the efficiency of a connection. If you have to waste a header for every 20 bytes, then you will have lower data throughput than if you could send packets up to 1500 bytes. Also, separate from the data over the wire speeds, computers generally process on a packet basis. That is, you will max out the CPU on a Windows system at a lower throughput with smaller packet sizes. Though the effect is lessened in *NIX systems because the TCP/IP stack is more efficient.

    5. Re:Warrent some (lots of) explanation by Cramer · · Score: 3, Interesting

      PMTU adjusts the maxiumum send size (mss) for a connection in a downward direction. It starts out at the interface MTU. Ethernet is limited to 1500 without some "jumbo frame" voodoo. (bad things happen when this value is increased on hardware/software that doesn't know how to deal with it.)

      BIC will only make a difference for "distant" nodes -- let's say 10,000miles (~16,000km). At that distance, it takes 89.408ms for the bits to get from end to end assuming it's a straight shot (no switches, routers, etc.) The initial connection opening will take 3x the link delay for the required SYN, SYN+ACK, ACK. It takes .12112ms to transmit a single packet. TCP will stop at 3 to 5 packets to await an ACK. In that time, 733 additional packets could have been sent. Jumbo frame (9KB) would increase throughput by ~6x, but there'd still be a 118packet-time pause. All this boils down to ~480KB/s with jumbo frames.

      (somebody go check my math.)

    6. Re:Warrent some (lots of) explanation by 680x0 · · Score: 1
      First, thanks for correcting my use of MTU vs MSS.

      I don't think the packet size makes much of a difference as far as when TCP will stop to wait for an ACK (remember, the TCP "window size" is specified in bytes (or "octets" for you networking weenies)).

      But, yes, you're correct in that it seems that the new work is addressing the effect when bandwidth allows you to transmit more data than fits in a window during the RTT (round-trip time). Perhaps they're increasing the number of bits used in specifying the window, but they definitely seem to be addressing the speed at which the default window size gets adjusted upward.

    7. Re:Warrent some (lots of) explanation by atomicdragon · · Score: 1

      My dual channel memory has a 6.4 GB/s bandwidth, so I would think it could at least collect the data, especially since this is likely for large scale applications with fast equipment. Altough I agree the headline is misleading for all of the reasons posted so far.

    8. Re:Warrent some (lots of) explanation by drinkypoo · · Score: 2, Funny
      Eventually, mark my words, we will all have fat, fat OC-192-style connections coming into our houses and our computers will be participating in many and varied p2p networks swapping whatever the hell it is we're swapping all the time, because people will want to do this shit and technology marches on so they can keep selling stuff to people who keep forking over fistfuls of cash so they can buy it, by which I mean you and I. People are greedy and so they will keep inventing new stuff so they can sell it, it's the face-stuffing american way right? Anyway I like it because I like playing video games and they keep getting better and better, so I'm really not bitching or anything. Technology is dandy, especially when it pays the bills.

      The only pity is that we're going to have all this stuff a really stunningly long time after they promise it to us. Big corporations treat us like battered spouses, they really do. At least when they plant a shiner on us it's a walkman or a big screen TV or something. But i'm looking forward to being able to download at 2.4GBps (aggregate). When the 8.9TB holo-video discs come out, I'll be glad to be able to download the 6.2TB rip in a reasonable period of time.

      I bet the latest geforce is still going to cost more than the whole rest of my damned system, though :(

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    9. Re:Warrent some (lots of) explanation by name773 · · Score: 0
      just a pot-shot guess

      how about a POTS-shot guess?
      you were talking about dsl

    10. Re:Warrent some (lots of) explanation by John+Courtland · · Score: 1

      That's what I was referring to. Thanks for flushing that out more.

      --
      Slashdot is proof that Sturgeon's Law applies to mankind.
    11. Re:Warrent some (lots of) explanation by noodler · · Score: 1

      "When the 8.9TB holo-video discs come out, I'll be glad to be able to download the 6.2TB rip in a reasonable period of time"

      have you ever SEEN the kind of compression artefacts you get on the 6.2TB holo-rips??.,
      I mean, it's so lossy that most of what you see are little cubes floating around .,

    12. Re:Warrent some (lots of) explanation by Cramer · · Score: 1

      delayed ACK and window size are completely independant. The system will only send so many packets before it pauses for an ACK. un-ACK'd packets must be held in memory in the event of a dropped or damaged packet, so there has to be some limit :-) What makes TCP "slow" is it's assumption that the link is unreliable. Thus, only a few packets are "blind transmitted" initially. The delay window can grow once the link reliability increases. 'tho I've not dug through the Linux network stack in some time, so I don't know how far ahead it will transmit.

    13. Re:Warrent some (lots of) explanation by 680x0 · · Score: 1
      Ok, I went back and checked some of my books. You may be confusing "delayed ACK" with what is called the congestion window. What I was calling "the window" is actually the send window. The congestion window is indeed measured in packets (or segments in TCP parlance).

      The congestion window is expanded by an algorithm called "slow start", which will only transmit a small number of packets before getting an ACK (either linearly (e.g. add 1), or exponentially (e.g. double each time), depending on the implementation).

      I believe delayed ACK means waiting a few milliseconds after you would ordinarily send an ACK, in case a packet is being sent from the receiving side on which the ACK bit can "piggyback".

      It's complicated, and I clearly don't understand it as well as I thought I did (but it will make for some interesting reading). OS developers (like Linux) are tweaking these things as time goes by, but it sounds like the article is describing a more extreme form of tweaking of these alorithms.

  30. Yeah but... by gilmet · · Score: 5, Funny

    Does it beat out AOL 9.0 Topspeed technology?

    --

    Every time you read this, I am going against my principles.
    1. Re:Yeah but... by Beatbyte · · Score: 1

      and has Orange County Choppers made a lame commercial about it yet?!

  31. Other uses of this technology... by Anonymous Coward · · Score: 0

    Some group of morons somewhere will think this is for motorcycles, and they will be badly injured because of the extra speed.

    Another group of morons will compress this data and market it for ten extra bucks to other morons who will eat it up.

    Another group of morons from the Washington area will write proprietary code that cannot possibly make use of this technology, thus dividing Internet access.

    Some dude with a floppy and a lot of time on his hands will use this technology to destroy mankind.

  32. What I really want to know... by Anonymous Coward · · Score: 0

    is how many libraries of congress I can download in a minute. *sigh* there should be mod points for campiness or lameness. Hense the anonymous coward :)

  33. And so... by Tuxedo+Jack · · Score: 4, Funny

    This becomes just another fast way to piss the RIAA off.

    --

    Striking fear in the authors of godawful fanfiction, I am here, appearing in darkness, Tuxedo Jack!
    1. Re:And so... by iNetRunner · · Score: 1

      If implemented RIAA would say that piracy increased 600000% and that they now lose so much money to piracy that their earnings are practically negative!

      --
      Store with salt
    2. Re:And so... by madfgurtbn · · Score: 1

      This becomes just another fast way to piss the RIAA off.

      Not as much the MPAA. They are the ones who fear the next generation of fat pipes.

      --
      Send lawyers, guns, and money. Dad, get me out of this.
  34. Re:1,000x... 2,000x... X,000x by rock_climbing_guy · · Score: 1

    Wasn't there a time when 1GB of RAM would have been overkill?

    --
    Wh47 d1d j00 541, 31337 15n't t3h r0xor5 ne m0r3???
  35. In other news.. by RajivSLK · · Score: 5, Funny

    I have developed a super fast car that is 6,000 times quicker than your driveway, an delicious orange that is 6,000 times tastier than your tongue and a new form of water that is 6,000 wetter than your garden hose!

    Please send lots of money in the form of grants to
    super inventor guy
    123 fake street
    v3n3r9

    1. Re:In other news.. by Anonymous Coward · · Score: 0

      Will you double my order if I call within the next ten minutes?

    2. Re:In other news.. by diablomonic · · Score: 1

      pissed myself laughing. in fact, I laughed 40000000000000 times louder than my tonsils.

      --
      watch "the money masters" on google video
    3. Re:In other news.. by WankersRevenge · · Score: 1

      Ah, I see you also work for Infinium. Wink Wink. Say no more. Say no more.

  36. Re:please don't do this. by fake_name · · Score: 5, Interesting

    Is second this notion. Here in Australia users on broadband have volume caps beyond which they have to pay for data at rather high rates, or suffer from their connections being cut back to the equivilent of a 28.8 Modem (depending on your ISP)

    The belief of USA based companies that bandwidth is "free" and that 30 second video clips are an acceptable form of advertising really hurts users in other parts of the world.

  37. Gigabit Ethernet? by Animats · · Score: 3, Funny

    They've discovered gigabit Ethernet! Wow!

  38. They left out a word by rock_climbing_guy · · Score: 4, Funny

    It's 6000x faster than MSN DSL, isn't it?

    --
    Wh47 d1d j00 541, 31337 15n't t3h r0xor5 ne m0r3???
    1. Re:They left out a word by embedded_C · · Score: 1

      Actually this is what they are running on those Earthlink commercials where downloads are N times faster than normal dialup!

  39. Let's slashdot the researchers site too by bigsexyjoe · · Score: 4, Informative
    Actually I'll just put the abstract below. If you want to read their paper, code, and other goodies, click here

    High-speed networks with large delays present a unique environment where TCP may have a problem utilizing the full bandwidth. Several congestion control proposals have been suggested to remedy this problem. In these protocols, mainly two properties have been considered important: TCP friendliness and bandwidth scalability. That is, a protocol should not take away too much bandwidth from TCP while fully utilizing the full bandwidth of high-speed networks. We presents another important constraint, namely, RTT (round trip time) unfairness where competing flows with different RTTs may consume vastly unfair bandwidth shares. Existing schemes have a severe RTT unfairness problem because the window increase rate gets larger as window grows - ironically the very reason that makes them more scalable. The problem occurs distinctly with drop tail routers where packet loss can be highly synchronized. Bic-TCP is a new protocol that ensures a linear RTT fairness under large windows while offering both scalability and bounded TCP-friendliness. The protocol combines two schemes called additive increase and binary search increase. When the congestion window is large, additive increase with a large increment ensures linear RTT fairness as well as good scalability. Under small congestion windows, binary search increase is designed to provide TCP friendliness.

    1. Re:Let's slashdot the researchers site too by Anonymous Coward · · Score: 0

      NCSU rules!!!

    2. Re:Let's slashdot the researchers site too by DoctorHibbert · · Score: 1

      Ok, after reading that I see they've made an advance in a problem that I never knew existed and barely even affects me.

      So thats, uh, good... right?

      --
      Arbitrary sig
  40. mirror by Anonymous Coward · · Score: 0
  41. Whoa... by officepotato · · Score: 1

    Deja vu.

    Comparing an actual signalling rate to "fast"? Where have I seen this recently?

  42. mirror by Anonymous Coward · · Score: 0
  43. Comment removed by account_deleted · · Score: 1

    Comment removed based on user account deletion

  44. MIRROR by Anonymous Coward · · Score: 0

    here is a mirror since the website appears to be dead or near dead:

    click here for mirror

  45. not steam, sonique! by Kiyooka · · Score: 2, Funny
    Data are collected at a remote location and need to be shipped to labs where scientists can perform analyses and create high-performance visualizations of the data.

    Visualizations of the data? So what, are they gonna all smoke up and watch Rabbit-Hole or Smear while "analysing" the data?

  46. Wrong date? by embedded_C · · Score: 1, 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?

    1. Re:Wrong date? by The+Happy+Camper · · Score: 1

      I think he meant the 1960's

    2. Re:Wrong date? by wayne606 · · Score: 1

      The day the internet switched to TCP/IP was in '82 I think. You'd have to go look at the RFC's to find out when the spec first came out but it's reasonable to call TCP an 80's protocol.

  47. So What.... by Sophrosyne · · Score: 4, Funny

    I've invented a pen that can write 6000 times faster than a pencil.
    (fine print: super human strength required, in order to reach maximum speed alterations of the laws of physics may be necessary.)

    1. Re:So What.... by Carnildo · · Score: 1

      I've invented a pen that can write 6000 times faster than a pencil.

      A better comparison would be a pen that writes 6000 times faster than a book.

      --
      "They redundantly repeated themselves over and over again incessantly without end ad infinitum" -- ibid.
    2. Re:So What.... by Zueski · · Score: 1

      The correct choice would be "invented words that write 150,000 times faster than a pencil" . . .

      --
      please don't feed the monkey
  48. More Information by Percy_Blakeney · · Score: 2, Informative
  49. Max DSL speed ? by Anonymous Coward · · Score: 1, Interesting


    i thought was about 8mbs theoretical max, which compared to ISDN is pretty hefty, but squeezing gb's down telephone cable just seems to be the realms of fantasy

    1. Re:Max DSL speed ? by Bushcat · · Score: 1
      i thought was about 8mbs theoretical max

      I have 70Mbps VDSL, up from 24Mbps ADSL. Sumitomo's MegabitGear does 70 Mbps, for example, but my kit is NEC. Infineon and others are working on 150 Mbps.

    2. Re:Max DSL speed ? by TheOnlyCoolTim · · Score: 1

      Do you guys have the same 4 wire copper wiring that we generally have in our POTS?

      Tim

      --
      Omnia vestra castrorum habetur nobis.
    3. Re:Max DSL speed ? by Bushcat · · Score: 1

      I dunno, there's only 2 wires at the jack though.

    4. Re:Max DSL speed ? by TheOnlyCoolTim · · Score: 1

      I made a dumb mistake, actually - the jacks can have four wires, but that allows for two lines on one jack...

      Tim

      --
      Omnia vestra castrorum habetur nobis.
  50. This one makes more sense by colman77 · · Score: 4, Informative

    This article is much clearer. http://www.csc.ncsu.edu/faculty/rhee/export/bitcp/

  51. And just when was TCP invented? by The+Happy+Camper · · Score: 2, Interesting

    "TCP was originally designed in the 1980s when Internet speeds were much slower and bandwidths much smaller,"

    Is it me, or did they miss by a couple decades there?
  52. suck it 6000 times by t_allardyce · · Score: 0, Troll

    oh please, 6000 times faster might be what you say to some unknowing muppet you're trying to sell a modem to, but this is slashdot, we expect nothing more than bit rate, modulation type and SNR & bandwidth requirements without having to click on the /.'ed article.

    --
    This comment does not represent the views or opinions of the user.
  53. Sorta. It's based on photo-optics. by Kiyooka · · Score: 4, Funny

    To be more exact, it's the bonfire system they used in Return of the King to signal to Rohan to come to Gondor.

    It's called the Bonfire-Utilizing Light System Hardware Infrastructure Technology (aka BULSHIT).

  54. saying faster than DSL is misleading by Anonymous Coward · · Score: 1, Interesting

    They are comparing DSL (physical transmition protocol) vs a congession protocol.

  55. And... by ShallowThroat · · Score: 0

    you will still get lag in Doom 3 multiplayer.

    --
    The "Insert Quote Here" line is almost as predictable as inserting an actual quote.
  56. You forgot pigeon by Anonymous Coward · · Score: 2, Funny

    Copper, Glass, Silicon and Pigeon

    1. Re:You forgot pigeon by Jayfar · · Score: 2, Interesting

      My bad %-) For the benefit of those who don't RTFRFCs, RFC1149 - Standard for the transmission of IP datagrams on avian carriers. Laugh, if you must, but RFC1149 has been successfully implemented. Need QOS? No problem - RFC2549.

    2. Re:You forgot pigeon by Cramer · · Score: 1

      ... Pigeon...

      Where does the air come in... the pigeon cannot fly in a vacuum. (and wouldn't live very long either.)

    3. Re:You forgot pigeon by Anonymous Coward · · Score: 0

      Much like copper wires are suspended in a vacuum ;-)

  57. Hmm by retro128 · · Score: 1

    Obviously they are not using the new protocol on their web site.

    --
    -R
  58. Real journalist: by Kiyooka · · Score: 1

    This new proposal of mine, of which I've already prepared seven previous ones, moves binary digits, or just "bits", along the "information super-highway" at more than a GAJILLION times the current speed.

    *pinky to mouth, dramatic closeup, music swells*

    That is, assuming mini-me stops humping the prototype, which I call Preparation H.

    References:
    [1] Long live Dr. Evil jokes.

  59. They have tires like that by Anonymous Coward · · Score: 0

    Go with bald tires, less traction, and traction = friction.

    Put them on your pinto... you'll go faster, you just can't stop!

    1. Re:They have tires like that by Anonymous Coward · · Score: 0

      I know you're probably just joking but that makes aabsolutly no sense at all, you need friction to go. A tire that is better at stoping will also be better at accelerating. (Ricer's are funny (and by funny I mean stupid).)

    2. Re:They have tires like that by B'Trey · · Score: 3, Informative

      It does make sense. (Sort of.) Traction is necessary for acceleration, not speed. Notice a top fuel dragster. Very wide wheels in the back - lots of traction for the wheel that hook the power to the ground. Very narrow, bicycle looking wheels in the front - minimal friction to slow the car down. If you want to go faster, but don't care how long it takes you to get up to speed (low acceleration but high speed), you want tires with low traction and thus low friction. If you want to get up to speed very quickly (lots of acceleration) you need lots of traction under the powered wheels.

      Notice the tires on a road bicycle. Very narrow, low friction tires. The human leg doesn't provide a great deal of power, so it's not necessary to have a great deal of traction to prevent spin out. Low friction means you go faster with less work. Now look at a mountain bike. Wide tires that get lots of friction. Great for riding rough, slippery trails at high speed. But not great for riding long distances on the road. Try doing a century on a road bike and then doing it on a mountain bike.

      Of course, on many cars low friction wheels are not going to give you any increase in speed. On my car, the rev limiter kicks in at just over 130. Low friction wheels would let me go that fast with a tad less work but it wouldn't help me go any faster.

      --

      "The legitimate powers of government extend only to such acts as are injurious to others." Thomas Jefferson.

    3. Re:They have tires like that by GMontag451 · · Score: 1

      You are neglecting air resistance. The limiting factor for top speed *is* acceleration, because you have to combat air resistance. The more acceleration you can get out of the tires, the more air you can push out of the way while maintaining speed. The friction of the tire is negligable compared to air resistance which goes up as the cube of the velocity IIRC.

    4. Re:They have tires like that by CornHole · · Score: 1

      You are correct.

      Side note: slicks for drag racing and circle track racing have no tread. More tire to ground contact = better traction (on smooth surfaces) so bald tires, with "sticky rubber" could, on a smooth surface, make your car go faster. To post on topic, I have DSL and bald tires, and neither my car's or my connection's speed is anything to brag about. Also, I like cheese!

    5. Re:They have tires like that by inertialmatrix · · Score: 1

      Just to point out..

      " Very wide wheels in the back - lots of traction for the wheel that hook the power to the ground. "

      If by traction you are referring to friction, and the friction coefficient between two surfaces - then the size/width of the wheel/tire has nothing to do with the actual traction. The surface area (width) of a tire has no effect on the total frictional force. FFRICTION = N

      When a car pulls up to a starting line and hooks up for a race by spinning the wheels, they are simply changing the friction coefficient of the tire material by heating it up.. and in doing so make the actual material "stickier". The reason for having wider wheels has particularly little to do with traction when it comes to a dragster because of the slick (no treads) tires that the car is running on; and much more to do with stability, thermal conductivity, and tread wear. As for the narrow tires at the front, well that is an aerodynamic/wight consideration.

      A big reason for wider tires on high horsepower, high torque cars is because of tread-wear and heat/thermal issues. Two different sized width tires both made out of the same material would wear differently. The narrower tire would wear quicker than the wider tire. Imagine 900 ft/lbs of torque transfered to a bike tire over a period of 20 seconds - enough torque to completely wear the tire resulting in a catastrophic failure. Also, larger tires having much greater mass are better able to deal with the intense thermal loads.

      " Notice the tires on a road bicycle. Very narrow, low friction tires. "

      Again, the width of the tire has nothing to do with the amount of friction (traction) they provide. If there is any difference in the traction between a bike tire, and a car tire it is most likely due to a difference in material, tire pressure, or tread pattern.

      All things being equal, tire width has nothing to do with traction vis a vis the ground/surface.


      cheers

    6. Re:They have tires like that by B'Trey · · Score: 1

      Saying that tire friction is your limiting factor implies that at some point, the engine is capable of providing more power but the tires start spinning and can not hook that power to the ground. I do not know of any car where the engine spins the tires out at top speed.

      You're correct in that air resistance often sets your top speed. An engine is capable of providing a set amount of power. At some point, the rolling resistance of the car equals the engine power output. That's your top speed. Air resistance is the largest part of your rolling resistance. Tire resistance plays a part as well, however, and decreasing tire resistance will give you a slightly higher top speed, assuming you don't reduce it so much that you DO start spinning out the tires at top speed and that your engine is capable of providing the power.

      However, this isn't always the case. An engine also has a top RPM. Imbalances in the engine mean that if you spin it too fast, its going to come apart on you. My car tops out at just over 130 because that's when the rev limiter kicks in. Even in a vacuum, with no air resistance (and assuming some method of feeding air to the engine, of course) my to speed would not change. Of course, that's an engineered limit and not a limit of physics. It would be possible to alter the gearing to allow the car to go faster at lower engine RPM, and thus allow the fundamental limits of physics to come into play.

      --

      "The legitimate powers of government extend only to such acts as are injurious to others." Thomas Jefferson.

    7. Re:They have tires like that by B'Trey · · Score: 1

      My first post was a bit simplistic and glossed over a few things.

      Friction has an effect on traction, but it isn't the entire story. You're correct, of course, that tire width has no effect on simple friction. That is, if you took a car and locked the wheels and measured the amount of force it takes to drag the car (over a smooth surface), that force will theoretically be the same regardless of the width of the tires. Narrower tires will have a smaller contact patch but will have more weight on that patch.

      However, traction involves more than just simple friction. There are a great many issues that come into play. One issue is the amount of unsprung weight - it takes more energy to spin a heavy wheel than it does a light wheel. You yourself mentioned that Wider wheels have greater mass. Since your engine puts out a fixed amount of power (fixed in the sense of a maximum output, power output varies over the RPM range of course), wider wheels require more of that power simply to rotate and that leaves less power to apply toward moving the car forward. Wider tires also have to move more air out of the way, which also takes energy (the aerodynamic issue you mentioned). Asphalt is not a smooth surface and is often litered with pebbles, bits of tire rubber and other debris. These tend to act like ball bearings and reduce the friction under the tire. A wider tire has a better chance of coming into contact with a solid surface. Wider tires can be built of softer compound and still stand up to the strain of a hard launch as the force is spread out over more material.

      In short, while simple friction is not affected by tire width, a wider tire does provide both more traction and more rolling resistance than a narrower tire.

      --

      "The legitimate powers of government extend only to such acts as are injurious to others." Thomas Jefferson.

    8. Re:They have tires like that by bkr1_2k · · Score: 1

      "Again, the width of the tire has nothing to do with the amount of friction (traction) they provide."

      I assert that, if you change the tire width, it does make the friction different. Now this isn't because of the surface area, though, it's because of the weight difference.

      I can make a huge difference in my speed on my road bike by changing from a 700x23 tire to a 700x25 tire. (By huge we're talking a couple miles an hour--for me at least) That extra 2 mm in width makes all the difference in the world for my top speed and length of time I can maintain a top speed. All because of the friction of my tires.

      for more info check out this page:
      http://www.school-for-champions.com/science /fricti on.htm

      A small excerpt
      "Independent of area

      The most important thing about the friction law or equation is that friction is independent of the surface area in contact. In other words, it is just as difficult to move a 1 cm square object as a 1 meter square object, if they both are pressed to the surface with the same amount of force.

      For example, it would take the same force to move a heavy desk across a wooden floor if the desk was on its side or if the desk was on its legs, provided the coefficient of friction was the same.
      Not intuitive

      This is not intuitive. You would think that there is more friction when the surfaces are larger. But the friction law states otherwise. You can verify this with experiments."

      bkr

      --
      "Growing old is inevitable; growing up is optional."
    9. Re:They have tires like that by smithmc · · Score: 1

      Of course, on many cars low friction wheels are not going to give you any increase in speed. On my car, the rev limiter kicks in at just over 130.

      Actually, it is very likely because of your tires that you're limited to 130 mph, but for a different reason. On many cars these days, the manufacturer chooses to electronically limit the speed of the car based on the speed rating of the stock tires. For many "regular" (i.e. non-sports, non-offroad, etc.) cars today, the popular choice is an H-rated tire, which is rated for 130 mph.

      --
      Downmodding is the refuge of the weak. Don't downmod, make a better argument!
    10. Re:They have tires like that by rthille · · Score: 1

      At/near top speed, the total amount of force the engine can generate isn't going to accelerate the car, but it is going to counteract air resistance. So, if you have a car with 200HP going at top speed (not rev/speed limited), your tires are taking all the force of those 200HP and applying it to the pavement. The difference between that situation and accelerating from a stop is that the potential differential in velocity between the road and the tire surface when at top speed is very low, but when starting from a stop that potential differential in velocity can be large.

      --
      Awesome furniture, accessories and cabinetry in Santa Rosa, CA: http://humanity-home.com/
    11. Re:They have tires like that by B'Trey · · Score: 1

      No, the car is rev limited. At approximately 500 RPM past red line, the compuer cuts fuel to the engine to prevent over-reving and blowing up the engine. It doesn't matter if you're in first gear or fifth. The engine will not turn above a certain RPM.

      --

      "The legitimate powers of government extend only to such acts as are injurious to others." Thomas Jefferson.

    12. Re:They have tires like that by B'Trey · · Score: 1

      Mostly correct. At top speed, the engine is working to overcome everything which is working to slow the car down. The majority of that is air resistance, but that isn't all of it. A car has a natural rolling resistance which the width of the tire affects. All other things being equal, a wider tire will increase the rolling resistance of the car.

      --

      "The legitimate powers of government extend only to such acts as are injurious to others." Thomas Jefferson.

    13. Re:They have tires like that by smithmc · · Score: 1

      No, the car is rev limited. At approximately 500 RPM past red line, the compuer cuts fuel to the engine to prevent over-reving and blowing up the engine. It doesn't matter if you're in first gear or fifth. The engine will not turn above a certain RPM.

      Yes, I'm sure it is rev-limited as well, but the same equipment is also often used to regulate top speed.

      --
      Downmodding is the refuge of the weak. Don't downmod, make a better argument!
  60. The Source by Urgo · · Score: 2, Interesting

    Instead of reading it from a blog here it is the source press release at the college. .. Still looking for the actual paper though..

    --
    Belive in Technology and AMAZE yourself. -- RIP ZDTV/TechTV
  61. N.C.S.U. link by Anonymous Coward · · Score: 0

    I hope none of you are planning to enroll there because of this. At least in the CS undergraduate department, I've found it to be a soul-sucking waste of time. I wish someone there would teach me something.

  62. Mike's oversimplified take on things. by IvyMike · · Score: 4, Insightful

    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.

    1. Re:Mike's oversimplified take on things. by Anonymous Coward · · Score: 2, Informative

      Mike's got it right.

      Why existing mechanisms don't work well: in order to be fair to other (TCP) network users, TCP only slowly increases how much bandwidth it sends. Even if you have a 100 Mb connection, if you've got a 100 ms ping time to somewhere, then in the first 100 ms TCP will only send 1500 bytes or so. In the next 100 ms, 3000. Depending on details, after that it may go exponential - 6k, 12k, 24k - but only to a limited point (often 32k or 64k bytes per RTT), after which it grows linearly at 1500 bytes per RTT.

      So what does that mean? Even with the exponential growth mode, if RTT is 100ms, you'll send less than 128kb in the first second your TCP connection is live, and it'll only grow by about 15kbps per second after that. So TCP transmitting as fast as it can for a minute sends well under 600kb, even if you have the whole 100 Mbps pipe available.

  63. timothygate, a dark day for 'geeks' by mynameis+(mother+... · · Score: 4, Funny

    A mistake of this magnitude really calls for the removal of ALL of his geek-points, immediate surrender of any ssh keys, termination of all accounts on any non-windows machines, immediate discontinuation of WEP encryption, reversion to SSID "netgear", and unrestricted enablement of "File & Printer Sharing".

    Unless he can demonstrate how a Honda can get more people somewhere than then the highway they now use... Well actually more like the license plate and turn signals on a honda but I'll let him off easy :)

  64. mirrored by Anonymous Coward · · Score: 0

    Mirror for when the site goes down Mirrored in advance for when the site goes down it seems a little sluggish

  65. Re:please don't do this. by Anonymous Coward · · Score: 1, Insightful

    It's not the US's fault that your country's ISP's are dickheads.

  66. Strange Jab... by ciroknight · · Score: 3, Funny

    Ever notice how the "Newest, High Speed Internet" is always being developed around particle accelerators? Maybe they really are trying to change the speed of light ;)

    --
    "Victory means exit strategy, and it's important for the President to explain to us what the exit strategy is." G.W.Bush
  67. Re:This one makes more sense (link to paper) by j1m+5n0w · · Score: 2, Informative

    htmlified link to pdf of paper and webpage for the lazy

    Lisong Xu, Khaled Harfoush, and Injong Rhee, "Binary Increase Congestion Control for Fast Long-Distance Networks", To appear in Infocom 2004.

    jim

  68. Rhee is my CSC316 teacher by bigginal · · Score: 4, Informative

    I'm in Dr. Rhee's CSC316 (Data Structures for Computer Scientists) course. He absolutely knows his stuff, but he can be very hard to understand sometimes. His website is here, with a picture of the guy that doesn't really do him justice. When he walks into the classroom, I swear he looks like one of the laid-back teachers that will just let you slide by through the course, but he *really* makes you learn the material, inside and out.

    Anyway, if you're interested in a link to the original article hosted off of the NCSU servers, it is here.

    -bigginal

    1. Re:Rhee is my CSC316 teacher by Anonymous Coward · · Score: 0

      dood...I had Rhee for CSC316 and he spent a good 50% of the class laughing at himself. I didn't learn much from him that I didn't read in the book.

  69. Clarification by Percy_Blakeney · · Score: 4, Insightful
    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.

  70. Forget lightspeed by Anonymous Coward · · Score: 2, Funny

    They jumped straight to ludicrous speed.

    1. Re:Forget lightspeed by Anonymous Coward · · Score: 0

      you must mean ludacris!
      haven't you learned how to spell from today's
      african american music artists?

      mystikal will learn you! hey ya, outkast knows
      what's up. snoop dogg is sniffin at your back!
      50 cent even knows his plurals.

  71. Your post is wrong on so many levels... by Pii · · Score: 1
    Remarkable, considering the brevity.

    Improper use of the apostrohpe notwithstanding, it's not a "technology that needs to be kept cheap and readily available."

    It's simply a more efficient Transport protocol (Layer-4). We're talking about an addition to the TCP/IP protocol stack, not a piece of machinery. It's a software change.

    --
    For those that would die defending it, Freedom
    has a sweet taste that the protected will never know.
  72. heh by rebelcool · · Score: 1
    56k modem faster than broadband.

    Maybe over plain copper wires. Phone company analog->digital sampling equipment (used between central office trunks) doesn't sample fast enough to allow speeds beyond 56K. Hence the reason there aren't any POTS modems beyond 56K anymore.

    --

    -

  73. allright... by TheHawke · · Score: 1

    So we got a higher compression protocol now. Just try to put it past Covad, Cox, Charter, SBC and all the rest of them to start using it. All those jokers will do is put a tigher cap on bandwidth useage when they apply it, not to mention attempting to twist the protocol to their advantage.

    --
    First rule of holes; When in one, stop digging.
  74. Haiku by Anonymous Coward · · Score: 0

    Well done.

  75. oooh... by Anonymous Coward · · Score: 0

    now you can slashdot unsuspecting websites 6,000 times faster

  76. Summary of Paper by HopeOS · · Score: 4, Informative

    First, the actual paper is more informative. The crux of the argument is as follows.

    If you have a fat pipe, say 1 to 10GB/s, standard TCP will not fully utilize the bandwidth because the congestion control algorithm throttles the rate. As packets move and there are no errors, the rate increases, but not nearly fast enough. In particular, it takes 1.5 hours of error-free data transfer to reach full capacity, and a single error will cut the connection's bandwidth in half.

    BIC-TCP uses a different algorithm for congestion control that is more effective at these speeds.

    End of news flash.

    -Hope

    1. Re:Summary of Paper by tolldog · · Score: 1

      Now that made sense. And I didn't have to read the article. Win/Win I say!

      -Tim

      --
      -I just work here... how am I supposed to know?
    2. Re:Summary of Paper by cballowe · · Score: 1

      I've sat down with 2 windows servers on opposite ends of an OC-3 with a 30ms latency (do the calculations -- standard TCP window size etc and you end up wit a maximum throughput of a little unde 2Mbps) and after some tuning of the registry, was pushing pretty close to the 100Mbps that the NICs in the servers could handle. This required enabling large windows, setting the default window size to something appropriately large, and making the send buffers big enough to account for it.

      TCP can be tuned easily enough to different networks, the paper discusses algorithms that are good without resetting parameters for different kinds of networks. Granted, tuning for a high latency network doesn't hurt you on a low latency network and if you know the network characteristics, tuning your TCP stack to match them will never hurt. ... Why search for the optimal window size if you know it at the start? ...

    3. Re:Summary of Paper by HopeOS · · Score: 1

      I didn't write the paper, so I can't really expound on the subject, but my own experience with network issues suggests that your statement is true if your OC-3 is normally under-utilized, but in heavy congestion, would not be as responsive to changes in the congestion pattern.

      This is to say that if your window sizes are already set to large values you can mitigate the long ramp time, but when congestion occurs, you'll still encounter the reduction in bandwidth, and unless your implementation is specifically tweaked to return to the large window sizes immediately, you'll have to wait it out. The BIC-TCP algorithm just takes larger steps and reacts more quickly.

      -Hope

  77. It's not like it matters... by cbreaker · · Score: 3, Interesting

    Even if we saw this tech to our houses, the ISP's would still nerf the connection at some lame ass speed like 768k/128k. I mean, cablemodems are capable of 40Mbit and they usually nerf it down to 1.5 Mbit/256Kbit. And no, most nodes are not saturated; before they capped my cablemodem (which was after three years of using it) I used to see 10Mbit on a regular basis, and easily T-1 speeds on the upstream. I live in a heavily populated area.

    --
    - It's not the Macs I hate. It's Digg users. -
    1. Re:It's not like it matters... by British · · Score: 1

      The problem is, while download speeds may increase, I sure as hell not seeing any upload speeds of websites(whether it's mom & pop or big biz) increase.

      We see the slashdot effect all the time. I don't think increased download speeds will help it. We'd just get "unavailable" messages quicker.

    2. Re:It's not like it matters... by sepsism · · Score: 2, Funny

      www.scienceblog.com/community/article2473.html Bandwidth Limit Exceeded The server is temporarily unable to service your request due to the site owner reaching his/her bandwidth limit. Please try again later. Apache/1.3.29 Server at www.scienceblog.com Port 80 oh the irony

  78. Dept by LittleLebowskiUrbanA · · Score: 0, Offtopic

    From the-wantssss-it-yessss-we-do-dept

  79. BIC-TCP by iminplaya · · Score: 3, Funny

    "connects first time, every time."

    --
    What?
  80. Re:Propagation delays: quantum teleporting by diablomonic · · Score: 1

    doesn't quantum information teleportation using entanglement solve this problem and allow instantaneous information transfer? imagine: pings of 0.1 millisecond to another country, or another planet. (solar system?)

    --
    watch "the money masters" on google video
  81. Attempt at distilling technical info by ezzzD55J · · Score: 5, Interesting
    As far as I can tell..
    • It is a transport-layer protocol, such as TCP, making statements such as "New protocol could speed Internet significantly" (the title on the article page) a bit bogus, but "BIC-TCP 6,000 Times Quicker Than DSL" utterly clueless.
    • It addresses the problem that TCP connections over low latencies get to adjust their windows faster than their higher-latencies buddies sharing a link, causing the lower latency TCP connection to get more of the bandwidth before the link is filled up (and both TCP's back off due to their congestion window).
    • The window size is adjusted using binary search instead of an exponential increase; somehow this makes this new protocol able to adjust its window size to the maximum (representing optimum bandwidth utilisation) faster than regular TCP. Why this is remains puzzling, because both binary search and TCP (which uses a factor of the previous window size) should reach their windows sizes in logarithmic time, as both searches are exponentially fast.

      "What takes TCP two hours to determine, BIC can do in less than one second," Rhee said.

      This is very puzzling indeed, the article doesn't back it up in the least.

    The rest of the article can be summarized as harmless fluff and clueless crud, as far as I'm concerned.
  82. It's a congestion control improvement by -tji · · Score: 3, Interesting

    It seems to be just a very poor choice of units to quote (he was probably trying to dumb it down to something the interviewer would understand).

    From the text of the article, it sounds like it's an improvement on TCP's congestion control performance (where it widens/narrows its transmission window to allow more packets to be outstanding between ACK's). Apparently they have some big improvements over current TCP, which allow it to fully utilize high bandwidth links. TCP takes time to expand the window and "fill the pipe". With the short-lived TCP sessions used for HTTP, this is not very efficient.

    Of course, for a small fee, I'll let you use my super-duper protocol that offers virtually unlimited bandwidth - a buttzillion times faster than DSL.. it's called UDP. (UDP is very low overhead, no transmission windows, or ACK's -- or guarantees of being received.. You can stuff them onto a line as fast as it will take them.)

    1. Re:It's a congestion control improvement by zenyu · · Score: 2, Informative

      Of course, for a small fee, I'll let you use my super-duper protocol that offers virtually unlimited bandwidth - a buttzillion times faster than DSL.. it's called UDP. (UDP is very low overhead, no transmission windows, or ACK's -- or guarantees of being received.. You can stuff them onto a line as fast as it will take them.)

      Yeah, but then you'll really want to be familiar with these new TCP congestion models since you'll need to implement something. A few years ago I had to connect a few computers on a relatively fat, but very noisy pipe, after realizing TCP was using a tiny fraction of the pipe I switched to UDP. Which led to 2 months of reimplementing TCP (cuz you really can't stuff packets as fast as it will take it) with a little FEC (forward error correction to deal) thrown in to deal with the noisyness. It was a good review of old signals and systems fundamentals, but if I had to do it over again I'd have simply refused to work with the supercomputer until they rewired my network connection to it. I can't imagine that would have taken a quarter of the time. IANANE, if I were, I might have enjoyed implementing a network protocol.

  83. 6000x to which dsl? by MoFoQ · · Score: 1

    Although it is still impressive if it's compared to US DSL, it would be more so if it's compared to Japanese/South Korean DSL, which is topping in the 40Mbps range (for roughly the same price as SBC Yahoo! DSL [$30]; they have 100Mbps [up and down] for around 50-60bucks a month).

  84. Of course... by tvh2k · · Score: 1

    Leave it to an AC to post such a ridiculous headline.

  85. The end of Copyright as we know it? by Anonymous Coward · · Score: 2, Interesting

    Sometimes a quantitative change in technology leads to a qualitative change in society. Witness what the emergence of DSL has done to the music and movie industries.

    Even if less than 1/100 of the claimed speeds were widely implemented this would probably signal the end of copyright as we know it.

    Why? Users would be able to exchange a lifetime's worth of movies, software - you name it- in a matter of days or hours.

    As socially disruptive as that might be one can imagine truly incredible new applications that would be far more socially disruptive:

    Every internet user could in effect become a TV broadcaster if they so desired. In charge of not just one channel but many. The best channels, like the best blogs, could become hugely politically and/ or culturally influential. The big TV networks' grip would almost certainly be loosened far more than it already has been by the arrival of the net (I rarely watch TV these days, like many of my friends).

    Even the above is just a microcosm of what could be achieved. Because if speeds of that order could ever widely implemented it would be like wiring together millions of neurons : you would end up with behaviour and results totally unexpected from examination of individual components of the system.

    Knowing all the above how many people here are willing to bet that if the "Powers that be" see such a technology looming on the horizon they will not try to kill it or severely cripple it from the outset ? Personally, I believe that if a technology is commercially and technically feasible then, in a market economy, it is almost impossible to stop.

  86. Re:Propagation delays: quantum teleporting by trompete · · Score: 2, Funny

    I'm more of a cup and string kind of guy! ;)

  87. real mirror by silicon1 · · Score: 3, Informative

    site is slow so I mirrored it: mirror

    1. Re:real mirror by davew2040 · · Score: 1

      Isn't that ironic?

  88. I can't wait... by SeinJunkie · · Score: 1

    for BICtorrent :)

  89. Comment by RAMMS+EIN · · Score: 0, Redundant

    [insert random lame remark about them apparently not using their shiny new tech cause The Fine Article Has Been Slashdotted here]

    I don't get the description of the story. BIC-TCP, a new protocol that is 6000 times quicker than DSL. How can a protocol be quicker than a transport layer? Or is the protocol a new technique that achieves 6000 times the speed over the same infrastructure as DSL?

    --
    Please correct me if I got my facts wrong.
  90. hmm... confusion reigns among the semi-journalists by joelja · · Score: 4, Interesting

    I suppose it makes sense that the semi-clued can't tell the difference between a transport protocol and a link layer protocol. The situation is futher obscured by the differences between the 4 layer IETF model for protocol stacks and the 7 layer osi model both of which are more or less obsolete when you start having things like link layer signaling effect what goes on in upper layers as many efforts in standards bodies aim to do just that or the converse.

    Basically though, things like bic-tcp, and a lot of tuning that you can do to just plain-old-tcp are there so people with really fat network connections can utilize them in some sane fashion with a compartivily small number of data flows...

    If you happen to have 10GB/s ethernet or oc-192 POS circuits into your office and need to move data in reasonable amounts of time this might be welcome news. There's nothing in here that amounts to a new link layer though, or really any technology that's useful in the near or long term future to more than a tiny subset of all transport consumers.

    A reasonable desktop machine built today can do a passable job of keeping a gigabit ethernet link full which is fine if you have one, but not so useful if you don't. While the computing power I have personally available to me at home has increased by a factor of around 10,000 or so in the last decade, the actual speed of my external network connectivity has only increased (And I'm being optimistic here) by a factor of around 100 (to 1.5Mb/s symteric). I don't see and evidence that that would indicated that this is likely to change anytime soon, although if we follow the trend-line out another decade maybe oc-3 style connectity will really exist to the home. The gap between computing resources and available bandwidth doesn't really seem likely to get any narrower however. Thusly our ability to use data (of any variety) that we have to transport over a network is necessarily constrained not by protocol inovation but by the pidling little link-layer connections that connect our homes workpalces to the rest of the network.

  91. What the professor is trying to say by OPTiX_iNC · · Score: 1

    is that 'his' protocol is really good at detecting when the pipe is full.

    The ISP here in belgium has something similar, when they detect your pipe is at max capacity, they increase it by 25% until you hit 10Mbps.

  92. If this technology gets off the ground ... by CrustyBread · · Score: 4, Interesting

    Just sometimes a quantitative change in technology leads to a qualitative change in society. Witness what the emergence of DSL has done to the music and movie industries.

    Even if less than 1/100 of the claimed speeds were widely implemented this would probably signal the end of copyright as we know it.

    Why? Users would be able to exchange a lifetime's worth of movies, software - you name it- in a matter of days or hours.

    As socially disruptive as that might be one can imagine truly incredible new applications that would be far more socially disruptive:

    Every internet user could in effect become a TV broadcaster if they so desired. In charge of not just one channel but many. The best channels, like the best blogs, could become hugely politically and/ or culturally influential. The big TV networks' grip would almost certainly be loosened far more than it already has been by the arrival of the net (I rarely watch TV these days, like many of my friends).

    Even the above is just a microcosm of what could be achieved. Because if speeds of that order could ever widely implemented it would be like wiring together millions of neurons : you would end up with behaviour and results totally unexpected from examination of individual components of the system.

    Knowing all the above how many people here are willing to bet that if the "Powers that be" see such a technology looming on the horizon they will not try to kill it or severely cripple it from the outset ? Personally, I believe that if a technology is commercially and technically feasible then, in a market economy, it is almost impossible to stop.

  93. You think that's good? by aled · · Score: 2, Funny

    My /dev/null is still faster in uploads.

    --

    "I think this line is mostly filler"
  94. OH THATS JUST GREAT!!!! by Anonymous Coward · · Score: 1, Funny

    Now my ISP Can shut me down for abusing Bandwidth after about 30 seconds......

  95. I've got two words fer ya! by MasTRE · · Score: 1

    Re-tarded! DSL is not "an Internet protocol." BIC-TCP (what, does it use BIC pens?) should be compared to TCP/IP, or, something..

    What's next? BIC-TCP is 1 billion times faster than President Bush? Probably, but it doesn't make any sense! (where is that "crazy" emoticon when you need it? :)

    --
    Must-not-watch TV!
  96. My fast computer by sburnett · · Score: 1

    Hey everybody! I just got a new computer that's 6000 times faster than the Internet! Wow!

  97. background by Minna+Kirai · · Score: 1

    The current TCP/IP implementation is described in RFC 2001.

    The problem addressed by both that document and this new paper is that an individual computer sending data onto the internet has no idea what the total bandwidth to its destination is, nor how many other users are trying to use that link. It has to guess. And if it guesses too high, then not only will that computer drop some packets (forcing them to be resent later), but other users of the network will experience needless drops too. (The computer's guess at the bandwidth number is sometimes called "congestion window")

    According to RFC2001, the computer keeps on gradually (linearly) racheting up the bandwidth it assumes the link can sustain, until a packet is lost (indicating that bandwidth has been exceeded). Then the assumed size is cut in half, and transmission resumes. This means that if you graphed the computer's guess at the bandwidth along side the actual avail bandwidth, it'd look like a sawtooth below the actual level.

    The problem there is if you've got say a 5 megabyte file, and a 500 megabit link, it might not send AFAP because by the time your computer learns there's 500 megabits available, the transmission is over. That's especially likely if the line has both high latency and bandwidth. Many people have tried to avoid that problem by increasing their guess faster than linearly, like exponentially. But that may be unfair to other users of the network, squeezing them out and hogging bps for yourself.

    Rhee's proposal is hopefully a way to allow super-linear acceleration, without stealing away too many packets from everyone else. (Remember that everyone else will eventually all be using the same scheme)

  98. In order of BW: by _ph1ux_ · · Score: 1

    Silicon, Glass, Station Wagon, Copper, Pigeon.

  99. It already IS implemented. by Ungrounded+Lightning · · Score: 4, Informative

    It would be interesting to know how far out an implimentation of such a protocol on a large scale is.

    It already IS implemented.

    Or do you mean a large-scale "rollout"?

    If so, why bother? Unless you have a REALLY fat pipe and need to use it all for one stream, of course. (But not many need to do that, and the ones that do can now install it on both end points.)

    The phrasing of the article is leading to confusion. This is about a PROTOCOL, not about the UNDERLYING TRANSPORT.

    The TCP protocol, with its windows, handshaking turnarounds, and timeouts, imposes its own limit on the speed of the data transfer through it. For decades the limit imposed by TCP was so far above the limits imposed by the data rates of the underlying transport that it wasn't a major issue.

    But now some people are starting to have REALLY fast pipes. And for them TCP is becoming the limiting factor.

    So now reasearchers have come up with a tweaked version of TCP that won't hit the wall until the pipe is a LOT faster than what YOU can rent from your ISP. (Unless you're renting an OC-192, in which you might be starting to fall a little short of its capacity. But if you've got OC-48 or below you're fine.)

    When you CAN rent something over 6 Gbps, and you want to routinely use it all for a single TCP connection to get a REALLY FAST fast download, you might want to ask the nice professors for a THIRD generation TCP. B-)

    Meanwhile, if you're on an ordianry connection you're not going to increase your data rate by a factor of 6,000 by switching protocols. You might get a little bit closer to the line rate with this SECOND generation TCP. But that's it.

    Expect to see this start to gradually start showing up in protocol stacks as an option - automatically configured if both ends know about it and the inventors have come up with a backward-compatible negotiation. That way you'll be able to make better use of fat pipes when you can finally get them.

    --
    Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
    1. Re:It already IS implemented. by Jodka · · Score: 4, Funny

      "That way you'll be able to make better use of fat pipes when you can finally get them."

      According to an email I received today they are already available and no prescription is required.

      --
      Ceci n'est pas une signature.
    2. Re:It already IS implemented. by ePhil_One · · Score: 2, Informative
      But now some people are starting to have REALLY fast pipes. And for them TCP is becoming the limiting factor.

      Its pretty darn easy to get really fast pipes. Motherboards ship with Gigabit ethernet now, Gigabit switches are way down in price. Most companies these days are building their networks on TCP/IP, this could be a pretty big thing corporate networks, iSCSI, etc. 10GigE isnt all that far away either.

      TCP/IP is bigger than the internet these days [admitedly, the server is down so I can't read the article]

      --
      You are in a maze of twisted little posts, all alike.
    3. Re:It already IS implemented. by Anonymous Coward · · Score: 0

      10GigE isnt all that far away either.

      Except that 10GigE has a much higher entry cost: it needs optical fiber.

    4. Re:It already IS implemented. by Anonymous Coward · · Score: 0

      Or you can FILL your post with RANDOMLY capitalized WORDS.

    5. Re:It already IS implemented. by WinterpegCanuck · · Score: 3, Funny

      When you CAN rent something over 6 Gbps, and you want to routinely use it all for a single TCP connection

      Dude, my computer can barely talk to my ram that fast . . . . I don't need the next paris hilton video quite that quickly.

  100. Cool Protocol..... by Anonymous Coward · · Score: 0

    ....now if they could develop a method of acquiring infinite bandwidth for their site.

    (Bandwidth Exceeded)

  101. Wally said . . . by Anonymous Coward · · Score: 0

    It's just like when Alice mantioned to Dilbert and Wally that Human Resources was giving out powerful anti-depressants that "may cause unwarranted optimism about your dead-end job", Wally said . . .

    "I gotta get me some of that."**

    So where do I trade in my DSL connection? It seems awfully slow now.

    **Dilbert 4/2/98

  102. The 56k limit by G27+Radio · · Score: 1

    The 56k limit on modems was because of the 64k circuits phone calls had to be routed through. The 8k difference is due to requirement of converting the signal from digital to analog and back to digital again. The 56k limit was imposed on the lines by the phone companies. Which was further knocked down to 53.3k due to FCC regulations or some bullshit like that.

    1. Re:The 56k limit by Anonymous Coward · · Score: 0

      8k difference is due to requirement of converting the signal from digital to analog

      Quantization noise isn't usually the primary problem with 56k modems. There's also the possibility of losing some of the bits from the 64kbps channel to channel signalling. Perhaps more importantly, not all of the possible PCM values are used; some of the smaller amplitudes are omitted to help the receiving modem more easily discriminate the original value. Some line cards do digital attentuation on the signal which adds some distortion.

      Which was further knocked down to 53.3k due to FCC regulations or some bullshit

      Transmitted power levels are limited by regulation. Some sort of limitation is necessary to standardize phone service, after all. I'm not sure that's "bullshit", as opposed to a required standard to keep your equipment from frying.

      At any rate, since the transmitted power is limited, so is the size of the possible constellation of quantization points. Not all the transitions are possible while meeting power limitation requirements.

    2. Re:The 56k limit by jimbosworldorg · · Score: 1

      1. 56K is what you get when you take a 64K circuit and use 7 bits of each word for data and the remaining 1 bit for signalling. 2. the FCC power level limit over POTS lines isn't to keep your equipment from frying, it's to keep your *head* from frying. The voltage is regulated low because the data is being transmitted over the same trunks used by analog telephones, in which the full electrical potential of the data circuit is delivered direct to the headset.

      --

      Coming soon to Slashdot: meta-meta-moderation!

  103. Where did you get your data? by Anonymous Coward · · Score: 0

    Light travels at 186,000 miles per second. Also known as 299,337,984 meters per second. And mapquest shows the distance between Cinci and Minneapolis is 1,141 KM. So, that would be 7.6ms round trip.

  104. 299,792,458 m/s by Anonymous Coward · · Score: 1, Funny

    or 186282.397 miles per second. Thank you very much.

  105. MOD THIS DOWN by Anonymous Coward · · Score: 0

    This is pure bullshit. Whoever moderated it as 'informative' should be shot.

  106. Re:please don't do this. by beest · · Score: 1

    Sounds like a policy problem rather than an issue American's should be concerned with. Hopefully you can spare some bandwidth to email your ISP and complain.

  107. Something I've always wondered... by Anonymous Coward · · Score: 0

    If you run programs on a tree, do you always get log(n) performance?

  108. new link by Anonymous Coward · · Score: 0

    Here's an alternate link for this story as the original site is having problems.

    http://www.ncsu.edu/news/press_releases/04_03/09 9. htm

  109. The Irony by TexVex · · Score: 1
    Clicked the link in the article, saw:
    Bandwidth Limit Exceeded
    --
    Fun with Anagarams! LADS HOST, SHALT DOS. HAS DOLTS. AD SLOTHS, HATS SOLD. ASS HO, LTD.
  110. Define Irony by kpwoodr · · Score: 2, Funny

    Irony == a website about speeding up internet traffic burning through all their bandwidth and having to shut down.

    --
    This sig has been removed pending an investigation.
  111. Pretty fast by MooseGuy529 · · Score: 1

    Bandwidth Limit Exceeded

    The server is temporarily unable to service your request due to the site owner reaching his/her bandwidth limit. Please try again later.

    Apache/1.3.29 Server at www.scienceblog.com Port 80

    Nice demonstration... his (probably) DSL-hosted server is now slashdotted 6000 times as quickly as before!

    --

    Tired of free iPod sigs? Subscribe to my blacklist

  112. excellent comparison! by kguilber · · Score: 0

    and my car gets fourty rods to the hogshead. and that's the way i likes it!

  113. Site Slashdotted by JGski · · Score: 1
    This Account Has Been Suspended

    Please contact the billing/support department as soon as possible.

    Somehow this message seems funnier on a site about new internet protocol than your typical slashdotted site.

  114. AND by chickenrob · · Score: 1

    is it OPTIMIZED?

    --
    People say my sig is the best thing about me.
  115. Information Theory by Anonymous Coward · · Score: 0

    I can't get to the article (slashdotted), but I assume they're saying that the new protocol can transfer more information than ordinary TCP. Note that is different to a data rate.

    If you reduce protocol overhead, you increase the amount of information while the data rate stays the same.

  116. Alternate Link Text by skzbass · · Score: 1

    RALEIGH, N.C. -- Researchers in North Carolina State University?s Department of Computer Science have developed a new data transfer protocol for the Internet that makes today?s high-speed Digital Subscriber Line (DSL) connections seem lethargic. The protocol is named BIC-TCP, which stands for Binary Increase Congestion Transmission Control Protocol. In a recent comparative study run by the Stanford Linear Accelerator Center (SLAC), BIC consistently topped the rankings in a set of experiments that determined its stability, scalability and fairness in comparison with other protocols. The study tested six other protocols developed by researchers from schools around the world, including the California Institute of Technology and the University College of London. Dr. Injong Rhee, associate professor of computer science, said BIC can achieve speeds roughly 6,000 times that of DSL and 150,000 times that of current modems. While this might translate into music downloads in the blink of an eye, the true value of such a super-powered protocol is a real eye-opener. Rhee and NC State colleagues Dr. Khaled Harfoush, assistant professor of computer science, and Lisong Xu, postdoctoral student, presented a paper on their findings in Hong Kong at Infocom 2004, the 23rd meeting of the Institution of Electrical and Electronics Engineers Communications Society, on Thursday, March 11. Many national and international computing labs are now involved in large-scale scientific studies of nuclear and high-energy physics, astronomy, geology and meteorology. Typically, Rhee said, ?Data are collected at a remote location and need to be shipped to labs where scientists can perform analyses and create high-performance visualizations of the data.? Visualizations might include satellite images or climate models used in weather predictions. Receiving the data and sharing the results can lead to massive congestion of current networks, even on the newest wide-area high-speed networks such as ESNet (Energy Sciences Network), which was created by the U.S. Department of Energy specifically for these types of scientific collaborations. 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. ?Now we are trying to apply it to networks that have several orders of magnitude more available bandwidth.? Essentially, we?re using an eyedropper to fill a water main. BIC, on the other hand, would open the floodgate. Along with postdoctoral student Xu, Rhee has been working on developing BIC for the past year, although Rhee said he has been researching network congestion solutions for at least a decade. The key to BIC?s speed is that it uses a binary search approach - a fairly common way to search databases - that allows for rapid detection of maximum network capacities with minimal loss of information. ?What takes TCP two hours to determine, BIC can do in less than one second,? Rhee said. The greatest challenge for the new protocol, he added, was to fill the pipe fast without starving out other protocols. ?It?s a tough balance,? he said. By allowing the rapid transfer of increasingly large packets of information over long distances, the new protocol could boost the efficacy of cutting-edge applications ranging from telemedicine and real-time environmental monitoring to business operations and multi-user gaming. At NC State, researchers could more readily visualize, monitor and control real-time simulations and experiments conducted at remote computing clusters. BIC might even help avoid a national disaster: The recent blackout that affected large areas of the eastern United States and Canada underscored the need to spread data-rich backup systems across hundreds of thousands of miles. With network speeds doubling roughly annually, Rhee said the performances demonstrated by the new protocol could become commonly available in the next few years, setting a new standard for full utilization of the Internet.

    --
    Sig (appended to the end of comments you post, 120 chars)
  117. Re:mirror-- Thanks by Avihson · · Score: 1

    account suspended... at least we can still read it.

  118. well, duh... by jpellino · · Score: 1

    of course it's faster - they're using a frikken' linear accelerator!

    "In a recent comparative study run by the Stanford Linear Accelerator Center (SLAC),"

    --
    "Win treats sysadmins better than users. Mac treats users better than sysadmins. Linux treats everyone like sysadmins."
  119. Re:If this {yeah like genetics} by jeoin · · Score: 0

    Its way to much information for an individual to barely begin to touch. Therefore impact would be neglibible. Lets see today in addition to my regular job I just want to peruse all the people in the worlds best creative gestures. Then i will have some coffee and fart.

    --
    Jeoin
  120. Quick decription by ziegast · · Score: 4, Interesting

    Seen on his website...

    BI-TCP is a new protocol that ensures a linear RTT fairness under large
    windows while offering both scalability and bounded TCP-friendliness.
    The protocol combines two schemes called additive increase and binary
    search increase. When the congestion window is large, additive increase
    with a large increment ensures linear RTT fairness as well as good
    scalability. Under small congestion windows, binary search increase is
    designed to provide TCP friendliness.


    My interpretation: This protocol would transfer data more efficiently than TCP/IP's teeny tiny packets and quickly figure out the correct packet size to maximize transfer speed. For similar reasons that a congested ATM network shreds the performance of multiple large TCP/IP data transfers, BI-TCP works better than TCP/IP at higher speeds. If you don't have OC-oh-my-god between your end-points, TCP/IP will continue work fine for you.

  121. Goddamnit! by SatanicPuppy · · Score: 1, Offtopic

    I posted this same article at 10:00am this morning, but apparently, as usual, it's just not as cool coming from me.

    --
    ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
    1. Re:Goddamnit! by Anonymous Coward · · Score: 0

      Just do what I have done. Quit submitting stories, its a complete waste of time. I urge everyone to do the same.

  122. Re:Time to Implementation? by tep-sdsc · · Score: 1

    Note that there have even been inter-operability studies with "the other" next-gen TCP stacks.

  123. http://www.csc.ncsu.edu/faculty/rhee/export/bitcp/ by blitzrage · · Score: 1

    Here is another site I found while googling for some more information. This website has a PDF document which seems to explain how the protocol works. However, I have not actually read the paper yet so I have no comment on it (I'm going to bed now. I'll read it in the morning).

    --

    I have no signature
  124. Poor web servers by Anonymous Coward · · Score: 0

    What about the poor web servers that will see their bandwidth jump by 6000... Will they be able to keep up?

  125. TCP can run a lot faster within a building. by Ungrounded+Lightning · · Score: 3, Informative

    But now some people are starting to have REALLY fast pipes. And for them TCP is becoming the limiting factor.

    Its pretty darn easy to get really fast pipes. Motherboards ship with Gigabit ethernet now, Gigabit switches are way down in price. Most companies these days are building their networks on TCP/IP, this could be a pretty big thing corporate networks, iSCSI, etc. 10GigE isnt all that far away either.


    The much higher speeds on a LAN are a good point.

    But.

    "The Wall" for TCP is a lot faster within a building than across a continent.

    The limit comes primarily from round-trip dealy - which is much shorter when things are microseconds apart then when they're milliseconds apart at speed-of-light-in-wire-or-fiber.

    The limit also comes from timeouts after lost or corrupted packets - from line flakeyness or congestion. But line flakeyness is nearly nonexistent on a LAN. As for congestion, if you're using switches rather than hubs it's also not as much of an issue within a building as it is in a cross-continent backbone.

    --
    Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
  126. MU! by inertialmatrix · · Score: 1

    FFRICTION = 'u' * N
    (the symbol for mu did not show up)

  127. Inappropriate measures by gringer · · Score: 1

    6000xDSL...

    Gosh, you could fit 540,000 olympic-sized swimming pools in the distance that the pipe would cover in a second.

    Or should that be, in the time it takes twenty five new /. readers to visit the site after it is first posted.

    --
    Ask me about repetitive DNA
  128. what about short-distance network with many hops? by tommeke100 · · Score: 1

    Apparently the test was on long lines. But does this adapt well to the internet? All protocols are good for some cases but not for others. I don't remember which protocol it was, but there has been a discussion on the length of the packets, and US wanted bigger packets since they have long lines, while Europe wanted smaller packets because they had smaller lines, more hops etc... Instead of focusing on the speed, I'd like to see some numbers in different network configuration :).

  129. W for Wireless! by Anonymous Coward · · Score: 0

    Don't cry radio, someone still loves you.

    (By the way, it's bloody stupid to use "W" for something that especially *lacks* wires. Like in "WLAN". Why didn't we have "Radio LAN"? Oh well.)

  130. Large scale rollout? by llauren · · Score: 1

    I wonder which gets rolled out on a large scale first; IPv6 or BIC-TCP?

    ~llauren

  131. Totally false title by TA · · Score: 3, Insightful

    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.

  132. NC State NOT North Carolina by PackMan97 · · Score: 1

    Let's get one thing straight! The article should read researchers from North Carolina STATE...!

    GO TO HELL CAROLINA! GO TO HELL!

  133. TCPs been a problem for years by bluGill · · Score: 1

    I used to work at a place doing mainframe networking. We easily beat TCP all the time in speed tests, even at T3 (45Mb/s) speeds. TCP can't fill your pipe very well when your link includes a satellite in Geo-synchronous orbit. (think 1 second or more for the packet to get there) There are not enough windows in TCP for those situations.

    However one thing we demanded was dedicated bandwidth, we could handle packet loss, but we made no effort to play nice with anyone else on the link. Course back in those days the internet backbones weren't fast enough to handle our customers anyway.

  134. academic dup by nothings · · Score: 1
    6,000 times faster than DSL? Strangely, that's exactly the same number that was hyped a year ago for CalTech's TCP replacement:

    Fast TCP To Increase Speed of File Transfers? and 8.6 GB Internet?

  135. yep too... by da5idnetlimit.com · · Score: 1

    But phone lines only uses 2 of the copper lines to get signal to the phone....

    Maybe if you used all 8 you could get 4 times the speed, using in fact 4 connections...

    In an Ethernet cable, all 8 lines are used.

    --
    It takes 40+ muscles to frown, but only four to extend your arm and bitchslap the motherfucker
  136. What does that mean for backbones? by cpghost · · Score: 1

    Let's assume for a moment that this 6000x faster-than-dsl technology is adopted by, say, 30% of the current dial-up population (a conservative estimation). This would mean, that the bandwidth of backbones would need to be upgraded to... how much exactly? 1000x-1500x? Wow!

    --
    cpghost at Cordula's Web.
  137. unless MY calculator is wrong by noodler · · Score: 1

    that should prolly be about 3.6 miliseconds, not 32.,., .,
    right shift by one decimal and you should be fine.,