Slashdot Mirror
New WiFi Protocol Boosts Congested Wireless Network Throughput By 700%
MrSeb writes "Engineers at NC State University (NCSU) have discovered a way of boosting the throughput of busy WiFi networks by up to 700%. Perhaps most importantly, the breakthrough is purely software-based, meaning it could be rolled out to existing WiFi networks relatively easily — instantly improving the throughput and latency of the network. As wireless networking becomes ever more prevalent, you may have noticed that your home network is much faster than the WiFi network at the airport or a busy conference center. The primary reason for this is that a WiFi access point, along with every device connected to it, operates on the same wireless channel. This single-channel problem is also compounded by the fact that it isn't just one-way; the access point also needs to send data back to every connected device. To solve this problem, NC State University has devised a scheme called WiFox. In essence, WiFox is some software that runs on a WiFi access point (i.e. it's part of the firmware) and keeps track of the congestion level. If WiFox detects a backlog of data due to congestion, it kicks in and enables high-priority mode. In this mode, the access point gains complete control of the wireless network channel, allowing it to clear its backlog of data. Then, with the backlog clear, the network returns to normal. We don't have the exact details of the WiFox scheme/protocol (it's being presented at the ACM CoNEXT conference in December), but apparently it increased the throughput of a 45-device WiFi network by 700%, and reduced latency by 30-40%."
In this mode, the access point gains complete control of the wireless network channel, allowing it to clear its backlog of data. Then, with the backlog clear, the network returns to normal
Yeah, and you'd never have another AP with the same channel on a different 'network'. How is the AP supposed to just instantly have 'total control'
"We don't have the exact details of the WiFox scheme/protocol, but apparently it increased the throughput of a 45-device WiFi network by 700%, and reduced latency by 30-40%." And what makes this different than Quality of Service (QOS)?
If WiFox detects a backlog of data due to congestion, it kicks in and enables high-priority mode. In this mode, the access point gains complete control of the wireless network channel, allowing it to clear its backlog of data. Then, with the backlog clear, the network returns to normal.
I am sure that there are absolutely no practical downsides
And, in practice, the system will never thrash when faced with realistic and unpredictable load.
Sounds like a research project that assumes a nice, friendly environment.
700% faster pr0n downloads!
Just when I get a new wireless router, more upgrades come out. I hope the other companies can provide a firmware download so the rest of us low-lifes can enjoy better connections.
Sounds like they're messing with 802.11 CSMA/CA min channel idle time and backoff on the AP to boost its transmit priority (and probably also force RTS/CTS handshaking when there's too many collisions between client transmits).
Neat idea, but not exactly new. Plenty APs optimized for WISP usage do this already.
Maybe the novel part is in dynamically determining congestion level or something...
I'm guessing this works to solve temporary channel congestion issues, and not over-subscription (to which the only real solution on my opinion is to get a bigger pipe at the over-subscription point). My guess is that they keep buffers for each of the host associated with the AP, and when one of the buffers begins to get to some relative threshold they ignore the RTS frames from the other stations and allow said buffer to clear to some min point before sending a CTS to the other stations.
If all of your associated host are simultaneously trying to send data in a full-mesh (all hosts talking to all hosts), I don't see how this would alleviate spectrum congestion (and you would think in this scenario latency would go up if they are round-robin'ing the queue clearing).
Implementation details would be sweet. To me this sounds like ETS queuing/COS as seen on enterprise wired L2/L3 switches. Have to wonder if there is any RED/WRED when queues reach max size? Speculation....
'We are trying to prove ourselves wrong as quickly as possible, because only in that way can we find progress.' RPF
The described scheme ( blah blah "priority mode" blah blah) addresses the described problem ( congested channel ) not at all.
Fuck systemd. Fuck Redhat. Fuck Soylent, too. Wait, scratch the last one.
Is this the same as last months "breakthrough" technology described in the MIT technology review.
http://www.technologyreview.com/news/429722/a-bandwidth-breakthrough
That breakthrough uses special coded TCP secret technology only known to the select few who sign the NDA. The rest of us have know it since 1951 as Hamming Codes, or more recently Forward Error Correction.
How about combining it with this technology from an earlier slashdot story: http://hardware.slashdot.org/story/12/10/23/1946248/increasing-wireless-network-speed-by-1000-by-replacing-packets-with-algebra
I do not believe its vaporware
http://sing.stanford.edu/fullduplex/
http://www.kumunetworks.com/
Sounds like this is based on the simple fact that most internet clients are consumers of data, not producers (high download to upload ratio). So if you make the access point more bossy, to the point of no longer playing nice and waiting its turn to transmit (thus it will be transmitting over the other devices in this mode), the overall result is more efficiency when moving larger amounts of data.
This makes sense on a number of levels. There is no point in letting client devices waste airtime requesting more data (again, assuming they are primarily consumers of data) when there is already a backlog of data that needs to be pushed down the pipe. Additionally, access points are centrally located and have higher gain antennas, thus even when they "double" with another device, there is a good chance that the recipient device will still be able to "hear" the access point over the other devices.
So I can see how this "high priority mode" would work, even if the formal protocol doesn't support it (ie the client devices can be totally stock). It's like being in a room full of people talking, and instead of waiting for people to quiet down to tell a friend across the room something, you simply start yelling. They are able to hear you because you're louder (higher gain antenna), and the other people don't have to quiet down either (since they're just talking).
There would likely be problems with this scheme when multiple access points have overlapping coverage - there would be lots of collisions at the fringe areas where they overlap. It would also have problems when someone is performing a large upload at the same time someone is streaming data down, because the access point would keep turning a deaf ear to the uploader. Also, if you had two clients sitting side by side, then that extremely close proximity could result in too strong of a client / client signal that the access point couldn't overcome.
Better known as 318230.
Well maybe the congestion is because the new wifi protocol has a cold? It is a newborn, after all, and more susceptible to colds!
Like it was/is sometimes used in ham-radio packet radio or in satellite communitation.
http://en.wikipedia.org/wiki/Demand_Assigned_Multiple_Access
The wikipedia description actually makes it sound a bit more complex than it actually it. In packet-radio DAMA simply meant that the central station polled each node regularly and asked it if it has queued requests. The only thing a client was allowed to send without asking back was the "I am a new client"-message.
My guess, this will be another scheme where the network driver on the client has to respond to congestion control/back-off style requests from the AP, staying off the air for a (random?) amount of time. The AP will just be slightly more sophisticated about who it tells to back-off. Even NTP has this feature.
Someone should tell the authors that "a jump from around 1Mbps to around 7Mbps" is a 600% increase, not a 700% increase.
Why is this concept so hard for people to understand?
Sheesh, evil *and* a jerk. -- Jade
Marge : Does anybody need that much porno?
Homer : Uuh-huuh-uuuh, 700%
Is this just randomly generated from other Slashdot posts, or is it from a select pile of posts full of Slashdotty keywords?
How about combining it with this technology from an earlier slashdot story: http://hardware.slashdot.org/story/12/10/23/1946248/increasing-wireless-network-speed-by-1000-by-replacing-packets-with-algebra
This I would like to see. To the increases stack? Do we get a 70000% increase? Do they even work together at all? It sounds like it would. Does anyone know or have the resources to find out?
Makes it sound like 700% gains are for everyone in the network. So we're to believe that occasionally discarding the buffered requests of a large subset of users magically solves a persistent congestion problem where more bandwidth is being demanded than is available? I suspect there will be a few happy users (who received priority) along with lots of sad faces.
Getting you the bandwidth back that you actually had before but couldn't remember you did with hugely inflated percentages based off of a specific set of circumstances!
You still keep posting these? You must be an idiot.
you don't get actual increase of max with this. it seems it's just a way to solve some congestion issues on highly loaded wifi networks.
world was created 5 seconds before this post as it is.
How about combining it with this technology from an earlier slashdot story: http://hardware.slashdot.org/story/12/10/23/1946248/increasing-wireless-network-speed-by-1000-by-replacing-packets-with-algebra
This I would like to see. To the increases stack? Do we get a 70000% increase? Do they even work together at all? It sounds like it would. Does anyone know or have the resources to find out?
The MIT technology is basically a way to cram more data into a packet, and a way to rebuild damaged (or even missing) packets without having to re-transmit.
This article is talking about dealing with packet congestion over the wireless medium.
Or to use a car analogy, the MIT method is like finding a way to shove more stuff in your trunk, and this method is like having a traffic cop in the street conducting traffic in areas where there are traffic jams.
So yes, they would be compatible. As for how much of a speed increase you'd see, it all depends on how congested the network is. The MIT method could potentially increase the effective bandwidth, but this method will not. In areas of high congestion it can prevent speed decreases, but it's not going to increase speeds on a network which isn't already congested.
Dear all
Sorry, but this method has been patented. Our man at the patent office lodged at least 5 minutes after^h^h^h^h^hbefore the information was released by NCSU. You can't have it. But look forward to seeing it in Airports real soon.
Sincerely
Apple Inc
This is the engineer-speak version.
Sales speak: "We can slash the R&D budget to nothing for the next 5 years by selling existing hardware with incremental improvements to the software stack, maximising our likelihood of getting a brand new Audi every six months. We should probably put a new fridge in the break room, though, so the peons don't get pissy about us shafting the consumer and not giving them a pay rise for the third year running."
Finally had enough. Come see us over at https://soylentnews.org/
Characteristic for improvements like this is that they stop being effective once everyone is using them.
For one day you will have 700% more througput, but once your neighbor finds that his throughput has dropped and installed the same software, the advantage is gone.
Remember, the problem of WiFi is not the management of a single channel, but the shortage of channels and the abundance of devices.
There are only 3 channels available and that is not enough to give every access point a clear channel to work on.
Grabbing more of the capacity of that channel is only changing the sharing of capacity, and thus it won't last.
Use an ethernet cable if you're at home. Faster AND more secure. Ok , you can't if its a smartphone or an ipad but I'm talking about when using proper computers, not toys.
Que an 'allways on' high-priority mode -hack (pushing the neighbours connections off-line) in 3 ... 2... 1...
As their txqueue fills up they are just shifting packets from the best effort queue to the video queue and then to the voice queue (highest priority). These queues use more air time and have less space between packets. I am curious how it performs under a variety of traffic conditions (upload vs. download vs. mix). It would seem that if uploads and downloads are done at the same time, the downloads will block the uploads. What if the clients do the same thing?
-- soldack
Then ISP's can throttle traffic to WiFi 1000% more effectively.
I haven't thought of anything clever to put here, but then again most of you haven't either.
If it's possible to boost it sevenfold, the effective bandwidth of a WiFi connection has to be less than 15 % of the nominal capacity.
I am beginning to think that what they are talking about here is as follows: the host recognizes is has a backlog of data. It sends all data to all stations at once. After the buffers are emptied, it then begins to poll the connected stations for their ACKs on that large databurst that was just sent. As long as the connected stations can hold onto those ACK packets for a few hundred milliseconds, all should be fine. The current way (I think) 802.11n works is that packets are sent one at a time and then the connected station is polled for traffic (the ack). We end up waiting for each client's TCP stack to checksum the packets and send ACKs. So why not send a huge databurst to all connected stations and then come around later polling for the ACKs? It saves us a lot of latency.
I toyed with the idea of queuing up 30 seconds of packets on the 1200 baud APRS network and then releasing them. In my case the point was to save on the horrific TXDelays of the radios... 600ms for the radio to come on frequency and stabilize to send a 1 second packet... or a 300ms packet. It made more sense to queue up packets and allow the TNC to send multiple packets with only one TXdelay. All of that said, I wonder if that's what they are proposing here?
Does anyone know what the timeout or guard time is for 802.11n DAMA polling? How long does DAMA wait for a station to not answer a poll for data before it gives up and polls the next station?
I remember back in the days of packet radio we used to queue up to 7 (gasp) packets at a time... it was common on the slow channel with many network hops to accumulate a backlog of packets which would all come in at once and then all be ACKed at once. I'm dating myself... NetROM days in the early 1990s.