BIC-TCP 6,000 Times Quicker Than DSL 381
An anonymous reader writes "North Carolina researchers have developed an Internet protocol, subsequently tested and affirmed by Stanford, that hums along at speeds roughly 6,000 times that of DSL. The system, called BIC-TCP, beat out competing protocols from Caltech, University College London and others. The results were announced at IEEE's annual communications confab in Hong Kong." Update: 03/16 04:46 GMT by T : ScienceBlog suggests this alternate link while their site is down.
Time to Implimentation? (Score:5, Interesting)
Propagation delays (Score:5, Interesting)
hmm (Score:5, Interesting)
"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.
Re:please don't do this. (Score:2, Interesting)
Re:please don't do this. (Score:5, Interesting)
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.
Re:Protocol faster than DSL? (Score:2, Interesting)
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.
Re:Propagation delays (Score:1, Interesting)
Max DSL speed ? (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
And just when was TCP invented? (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?Re:Protocol faster than DSL? (Score:2, Interesting)
saying faster than DSL is misleading (Score:1, Interesting)
The Source (Score:2, Interesting)
Re:Protocol faster than DSL? (Score:5, Interesting)
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's not like it matters... (Score:4, Interesting)
Re:You forgot pigeon (Score:2, Interesting)
Attempt at distilling technical info (Score:5, Interesting)
"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.
It's a congestion control improvement (Score:4, Interesting)
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.)
The end of Copyright as we know it? (Score:2, Interesting)
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.
hmm... confusion reigns among the semi-journalists (Score:4, Interesting)
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.
If this technology gets off the ground ... (Score:4, Interesting)
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.
Re:Time to Implimentation? (Score:3, Interesting)
Re:Warrent some (lots of) explanation (Score:3, Interesting)
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
(somebody go check my math.)
Quick decription (Score:5, Interesting)
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.