Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

New WiFi Protocol Boosts Congested Wireless Network Throughput By 700%

samzenpus posted about 2 years ago | from the greased-lightning dept.

Network 130

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

cancel ×

130 comments

Sorry! There are no comments related to the filter you selected.

first (-1, Offtopic)

xdcx (2711191) | about 2 years ago | (#41988061)

YES. we are getting closer to playing battle bots on MARS

Um... (1)

Anonymous Coward | about 2 years ago | (#41988069)

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'

Re:Um... (3, Informative)

Bruce Perens (3872) | about 2 years ago | (#41988695)

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'

Just of its own clients and other stations that can hear it. Some packets will potentially be lost due to the hidden-transmitter problem.

Re:Um... (1)

tattood (855883) | about 2 years ago | (#41992393)

Doesn't the AP already have complete control over the channel?

Best example of Vaporware I've heard in a while (2, Funny)

madsci1016 (1111233) | about 2 years ago | (#41988095)

"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)?

Re:Best example of Vaporware I've heard in a while (5, Informative)

Anonymous Coward | about 2 years ago | (#41988219)

> And what makes this different than Quality of Service (QOS)?

You could, you know, RTFA.

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

QoS just prioritizes packets in the buffer for transmission. It does nothing about spectrum. This scheme seems to have the AP tell all of the clients to STFU and get off the spectrum whenever it has a backlog of packets to dump.

Re:Best example of Vaporware I've heard in a while (1)

icebike (68054) | about 2 years ago | (#41988547)

Still one has to ask how much bandwidth the other units get while the porn downloader gets full bandwidth just so the router can clear its buffers.

It seems like this scheme favors the worst offenders, and imposed delays on the rest of the network users instead of telling the flooder to STFU.

We've been using TCP/IP for decades and burned up thousands of hours in queuing theory, simulations, etc. What is the chance they missed something that big?

Re:Best example of Vaporware I've heard in a while (0)

Anonymous Coward | about 2 years ago | (#41989119)

Data is data. It doesn't matter if it's goatse or the local church newsletter.

Re:Best example of Vaporware I've heard in a while (3, Funny)

jamesh (87723) | about 2 years ago | (#41990027)

Data is data. It doesn't matter if it's goatse or the local church newsletter.

You won't be saying that if those packets get transposed... some poor guy will sit down for a quiet evening of contemplating goatse and instead will be confronted with the word of god!

Re:Best example of Vaporware I've heard in a while (1)

lxs (131946) | about 2 years ago | (#41991587)

When you stare into the abyss the abyss stares back at you.

Re:Best example of Vaporware I've heard in a while (1)

weiserfireman (917228) | about 2 years ago | (#41991755)

I was at a training session last week by a wireless network vendor. One of the people in the class was a programmer from MetaGeek, who happens to work on Wireless Packet Capture Analysis software.

He did a 5 minute capture of the activity in the conference and then showed the results. Consistently, the iOS devices in the room were reserving significantly larger amounts of time on the Access Point, and then using a fraction of the time. This would reduce the amount of bandwidth available for other devices. iOS wasn't the only device doing that, but it was more extreme in the behavior.

If you had an access point, that under heavy loads that could ignore that type of behavior, not allowing devices to reserve time, it would improve throughput for everyone.

Re:Best example of Vaporware I've heard in a while (1)

Nutria (679911) | about 2 years ago | (#41988769)

That seems to turn the WAP from a hub into a switch.

Re:Best example of Vaporware I've heard in a while (0)

Anonymous Coward | about 2 years ago | (#41988893)

No, it's still a hub because everyone still uses the same channel.

Re:Best example of Vaporware I've heard in a while (2)

icebike (68054) | about 2 years ago | (#41989073)

No, it's still a hub because everyone still uses the same channel.

No, you've missed the point. Nutria had it right.

  It is almost exactly like converting the AP from a hub to a switch, because the AP gets to tell all the stations to STFU, and then handles traffic of each station one at a time, giving each at full upstream bandwidth, while the other stations wait until are allowed to speak. Switch.

Read carefully the Abstract at the bottom of this page: http://news.ncsu.edu/releases/wms-gupta-wifi/ [ncsu.edu]

Re:Best example of Vaporware I've heard in a while (1)

Muad'Dave (255648) | about 2 years ago | (#41991411)

So they've created on-demand wireless token ring [wikipedia.org] (really token-bus, given the topology) except that the AP controls who gets the token?

Re:Best example of Vaporware I've heard in a while (3, Informative)

tattood (855883) | about 2 years ago | (#41992505)

the AP gets to tell all the stations to STFU, and then handles traffic of each station one at a time, giving each at full upstream bandwidth, while the other stations wait until are allowed to speak. Switch.

That is absolutely not how a network switch works. In a switch, every connected device can send and receive on a completely separate collision domain from any other device connected. They basically implemented Token Ring [wikipedia.org] on wireless.

Re:Best example of Vaporware I've heard in a while (1)

wvmarle (1070040) | about 2 years ago | (#41989057)

I wonder how they can gain 700% performance gain. It sounds just too much.

Why? Because there is a limit to the total amount of data an access point can handle: this is a hard limit, defined by the WiFi protocols and transciever hardware. This would suggest that a congested access point handles no more than 12% of the maximum traffic - and that is for all the connected nodes together.

If a protocol can handle say 10 Mbit/s, then you can't magically make it 80 Mbit/s. So to have 700% gain, you have to start off at a mere 1.25 Mbit/s throughput. If 45 clients are actively using an access point at the same time, it's hard to imagine that this access point is doing only 1.25 Mbit of traffic, and that prioritising some traffic would suddenly boost that to the full 10 Mbit. Actually in such a situation I would really expect the access point to become saturated, and to be transmitting data at nearly 10 Mbit/s, and that if there is a serious backlog of data to be transmitted that this is due to lack of spare bandwidth.

Re:Best example of Vaporware I've heard in a while (0)

Anonymous Coward | about 2 years ago | (#41990277)

Probably not really that surprising, really. I haven't done the math (or read the article!) but I used to deal with things like this on proprietary wired networks, negotiating who gets to speak, and dealing with collisions when someone gets it wrong are extremely wasteful of bandwidth.

The summary didn't say it was taking a 54mbps WIFI channel to 378mbps with only a software change, it says (or at least implies) that the effective transfer rate, across all devices connected to that WIFI AP is increases by 700%. big difference.

Re:Best example of Vaporware I've heard in a while (1)

suutar (1860506) | about 2 years ago | (#41992517)

TLDR version: the main performance killer in a wireless net is retransmit delays due to packet loss and collision. Reduce those by any means and your effective speed goes up a _lot_.
Thing is, there's medium speed, which is what you're talking about, and there's perceived speed, which is 'how long does it take to download my file', which includes things like retransmit delays. There was an article a few weeks ago that illustrated that if you can reduce retransmits by reducing collisions and/or packet loss, you can get some really huge improvements in perceived speed without any change to the speed of the medium.
Example: 50 megabit medium, 5 megabyte (40 megabit) file, which comes to around 3300 packets. Assume 1% collisions, that's 33 retransmits. Retransmits in TCP/IP start with 'wait a second and try again' so that's 33 seconds of waiting. So 0.8 seconds data transfer, 33 seconds of delay, total about 34 seconds. Cut the collision rate in half by moving to a "one speaker at a time" model, and you've doubled your perceived speed. Cut it down to 4 collisions and your effective speed is about 7x what it was before.

Re:Best example of Vaporware I've heard in a while (1)

soldack (48581) | about 2 years ago | (#41991073)

While the AP is sending faster and more often, clients will suffer. If the AP is blasting to client A, client B will struggle to upload. This may cause client B to disconnect or reassociate. It isn't clear how they prevent starvation at the client transmit side.

Re:Best example of Vaporware I've heard in a while (1)

suutar (1860506) | about 2 years ago | (#41992587)

Yeah, but while the AP is blasting to A, A isn't sending more requests (or even ACKs), so the buffers will not just refill. Once the AP is done emptying its buffers, B should have the same ability to talk as A. I'm not saying there can't be pathological cases, but it doesn't seem likely to be a very common occurrence.

Re:Best example of Vaporware I've heard in a while (4, Insightful)

MarcQuadra (129430) | about 2 years ago | (#41988475)

The difference is that most network admins shirk from the task of responsibly implementing QoS, but they'd gladly pay a hefty licensing fee to their wireless vendors for a product with a name like WiFox that 'boosts performance' by clobbering the network instead of cleverly balancing it to perform well.

Re:Best example of Vaporware I've heard in a while (2)

NatasRevol (731260) | about 2 years ago | (#41988535)

Or that most wifi networks aren't managed by actual network admins.

Re:Best example of Vaporware I've heard in a while (5, Informative)

fsterman (519061) | about 2 years ago | (#41988587)

And what makes this different than Quality of Service (QOS)?

- madsci1016

The difference is that QOS is a passive buffer queuing mechanism that is susceptible to buffer bloat [wikipedia.org] , when large buffers (meant to help traditional QOS) trick the avoidance congestion algorithms,

...buffers have become large enough to hold several megabytes of data, which translates to 10 seconds or more at a 1 Mbit/s line rate used for residential Internet access. This causes the TCP algorithm that shares bandwidth on a link to react very slowly as its behavior is quadratic in the amount of buffering"

WiFi has a LOT of dropped packets and huge buffers, so the problem is vastly magnified. QOS over wifi involved a LOT of voodoo, and it's why P2P had such a negative impact on a network despite QOS. The fix is an active queuing [wikipedia.org] mechanism, like WiFox.

The difference is that most network admins shirk from the task of responsibly implementing QoS, but they'd gladly pay a hefty licensing fee to their wireless vendors for a product with a name like WiFox that 'boosts performance' by clobbering the network instead of cleverly balancing it to perform well.

- MarcQuadra

Uhh, no [wikipedia.org] ... the traditional balancing mechanisms are making it worse,

In a network link between a fast and a slow network packets can get backed up. Especially at the start of a TCP communication when there is a sudden burst of packets, the link to the slower network may not be able to process the sudden communication burst quickly enough. Buffers exist to ease this problem by giving the fast network a place to push packets, to be read by the slower network as fast as it can. However, a buffer has a finite size: it can hold a maximum number of packets, called the window size. The ideal buffer has a window size such that it can handle a sudden burst of communication and match the speed of that burst to the speed of the slower network. This situation is characterized by a temporary delay for packets in the buffer during the communications burst, after which the delay rapidly disappears and the networks reach a balance in offering and handling packets.

Network links have an inherent balance which is determined by the packet transmission and acknowledgement cycle. When a packet is sent, TCP usually acknowledges it before it will accept the next packet. This means that a network must transmit a packet and then transport the acknowledgement back before the next packet is pushed into the link. The time it takes to transport a packet and transport back the acknowledgement is called the round-trip time (RTT). If a buffer is large enough to handle a burst, the result will be smooth communication with (eventually) a low delay for packets in the buffer. But if the buffer is too small, then the buffer will fill up and will itself not be able to accept more packets than one per RTT cycle. So the buffer will stabilize the rate at which packets enter the network link, but it will do so with a fixed delay for packets in the buffer. This is called bufferbloat: instead of smoothing the communication, the buffer causes communication delays and lowers utilization of the network link (i.e. causes the network link to carry less than its capacity of packets).

Re:Best example of Vaporware I've heard in a while (1)

fsterman (519061) | about 2 years ago | (#41988751)

Whomever modded this down, would you mind explaining why? I honestly want to know if I have any factual errors :)

Re:Best example of Vaporware I've heard in a while (5, Informative)

Anonymous Coward | about 2 years ago | (#41989265)

I'm guessing it's because you made a brief mention of P2P which didn't involve bowing down and worshipping the protocol. The more sane mods have apparently fixed it, as you're at +5 Informative right now.

I would like to add some information about QoS. It's actually got very little or nothing to do with buffer bloat in the way you describe. It's easier to illustrate by thinking about a simple point-to-point link. There are actually two types of buffers- one at each interface and another in the routing/switching engine. The buffer we're talking about exists at the interface level, it's a FIFO type queue. The switch/router which is sending the data decides what order to place packets on the interface based on the QoS markings, but once they are in the buffer they come out the same order they go in. On the other end of the link, the packets arrive on the interface and get buffered before arriving on the switching/routing engine- again it's a first-in-first-out queue. Once the switching/routing engine gets the packets, it can then determine what order to push them to the next interface based on QoS markings.
Generally speaking, as long as there is enough available bandwidth on a link, QoS isn't really going to have much noticeable effect on the traffic. And just for the record, QoS only matters within YOUR network- never expect your QoS markings to have any effect when the traffic goes to someone else's network. If you try to honor external QoS markings, sooner or later some asswipe will notice and just start marking all HIS data at the highest priority level, and then you're back to square one.

Now what this article is talking about is a different scenario, it's actually a very old and simple problem... unfortunately the solution in this case is not so simple. Wireless access points operate like a hub- everything is in the same collision domain. This means that all the devices are filling up the same buffer on the wireless interface on the AP, and the AP's outgoing buffer is handling the traffic to all those devices as well. And aside from every device using a unique frequency channel (not feasible), there's no way to really resolve this like we can with wired mediums. So what they've done is come up with a software-based solution which makes the wireless AP act like something halfway between a hub and a switch... we don't really know more than that because they haven't released the details yet.

Re:Best example of Vaporware I've heard in a while (0)

Anonymous Coward | about 2 years ago | (#41989439)

Thanks, mod parent up btw.

Re:Best example of Vaporware I've heard in a while (1)

icebike (68054) | about 2 years ago | (#41989087)

The difference is that most network admins shirk from the task of responsibly implementing QoS,

Maybe that is because its impossible to implement QOS over anything but the smallest of networks, and then only for a subset of users.

Re:Best example of Vaporware I've heard in a while (0)

Anonymous Coward | about 2 years ago | (#41989511)

Ask someone more competent then.

Re:Best example of Vaporware I've heard in a while (1)

philip.paradis (2580427) | about 2 years ago | (#41989659)

It's not a matter of competency. It's a matter of others outside your network not giving a shit about your QoS preferences.

Re:Best example of Vaporware I've heard in a while (1)

skids (119237) | about 2 years ago | (#41991209)

You know not of what you speak. WiFi QoS schemes are generally just extensions of diffserv, so they are only really useful for prioritization based on what the endpoints set as a QoS classification, or if you think packet mangling is a good idea, based on what your routers can and cannot do with these flags. You can also base classifications on your own policy about applications on a very coarse level. None that I have seen offer any QoS-based per-connection fairness solution, e.g. WFQ or SF-BLUE, using the QoS channels, whether that might be technically feasable or not -- us network admins rely on the vendors to figure that out, because "competence" in our profession does not include coding our own AP OS or clients. So about the only thing they are good for is keeping web browsers out of a video/voice session's hair.

Re:Best example of Vaporware I've heard in a while (1)

mellon (7048) | about 2 years ago | (#41991893)

Actually, the usual reason for a WiFi network to be slow is not a lack of QoS-based routing, but rather bufferbloat [wikipedia.org] , which is what happens when transmit queue buffers in a router or bridge are not tuned to the carrying capacity of the transport. This results in packets being transmitted late, and hence their responses coming late, which fools the TCP congestion control algorithm and causes it to stutter. The result is that although there is sufficient bandwidth on the link, people don't get to use it, because most of the bandwidth is lost either to timeouts or retransmissions.

It's surprising that NCSU has this weird technique that they've no doubt patented; you could just download a copy of CeroWRT [bufferbloat.net] . The linux kernel was patched a while back to support CertWRT's anti-bufferbloat algorithm, but unfortunately right now you also have to apply custom configuration to the router to tune the buffer size to the capacity of your link.

Research project != practical application (1)

Anonymous Coward | about 2 years ago | (#41988147)

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.

Re:Research project != practical application (1)

icebike (68054) | about 2 years ago | (#41988565)

Exactly my thoughts.

What is the likelyhood that something simple, fair, and with no elephants hiding in the bushes has been missed by all the queuing experts lo these many years?

Re:Research project != practical application (0)

Anonymous Coward | about 2 years ago | (#41990347)

honestly, it sounds like it really was something that was simply missed by everybody. i mean, they're basically implementing traffic lights into a ridiculously busy uncontrolled intersection. QoS may be able to get it to behave like a all-way stop intersection, but WiFox puts in a full blown traffic control.

Re:Research project != practical application (0)

Anonymous Coward | about 2 years ago | (#41989581)

It breaks if there is more than one AP on the channel (which in the domestic situation is almost certainly true).

Two WiFox routers on the same channel would cause chaos if they both went into burst mode at the same time.. Probably you'd end up with 0% throughout.

That means... (1)

Anonymous Coward | about 2 years ago | (#41988175)

700% faster pr0n downloads!

Dammit! (1)

jennatalia (2684459) | about 2 years ago | (#41988199)

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.

Re:Dammit! (0)

Anonymous Coward | about 2 years ago | (#41988255)

Didn't you idiot? If not vaporware, this is really useful on massively use public routers. Not your average home or business router.

Re:Dammit! (4, Funny)

Githaron (2462596) | about 2 years ago | (#41988501)

Idiot is a verb now?

Re:Dammit! (5, Funny)

Anonymous Coward | about 2 years ago | (#41988789)

Idiot a fucking dictionary, noob.

Re:Dammit! (2, Funny)

Anonymous Coward | about 2 years ago | (#41988797)

Idiot a fucking dictionary, noob.

Fuck you and the horse you idioted in on!

Re:Dammit! (0)

Anonymous Coward | about 2 years ago | (#41989047)

Made me chuckle. Mod UP!

Re:Dammit! (0)

Anonymous Coward | about 2 years ago | (#41988279)

This is not for your home network, which is probably already plenty fast. It's for airports and busy conference centers where dozens of people are connected at the same time. The protocol prioritizes traffic for conservative Republican businesspeople, lowers priority for the 99%ers, and if you're part of the 47% who receive government handouts your packets are dropped.

Re:Dammit! (1)

egcagrac0 (1410377) | about 2 years ago | (#41989271)

I don't understand why the 47% feel entitled to free internets.

Catchy name for an old idea? (5, Interesting)

Anonymous Coward | about 2 years ago | (#41988221)

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

Re:Catchy name for an old idea? (2)

transporter_ii (986545) | about 2 years ago | (#41990369)

Yes this is true for WISPs, however, you have to use the proprietary protocol at the AP and the Client side (subscriber unit). This is something if it helps with just the AP and the clients don't need to upgrade.

Also, the AP running slow at the airport is not just because it uses one channel. If someone is hammering WiFi, it tends to let that person use more bandwidth then they should, but your AP at your home out in the middle of the country does OK with one channel and multiple people using it.

The issue in an airport is that there are only 3 non-overlapping channels in the 2.4 Ghz band. Go to an airport and do a scan. There is often an AP on almost every channel, 1 - 11. The non-overlapping channels are 1, 6, 11. That person that set their AP to 3 is interfering with channel 1 and channel 6.

WiFi has collision avoidance. I bet the new protocol will help in the airport for a while because if it just pushes out data, the other APs in the area will back off. But when everyone has this new AP...I really have doubts that it can plow through RF interference and keep the 700% speed boost.

WiFi was designed poorly from the start. There should have been 11, 5 Mhz channels that didn't overlap. This would have made it slower, but an AP at an airport would have worked a lot better with 11 true channels to use. If people needed more speed at home, they could have logged in and combined channels to make them 10 or 20 Mhz.

Re:You 1nsensiti^ve clod! (0)

Anonymous Coward | about 2 years ago | (#41988671)

Is this just randomly generated from other Slashdot posts, or is it from a select pile of posts full of Slashdotty keywords?

Re:You 1nsensiti^ve clod! (0)

Anonymous Coward | about 2 years ago | (#41988965)

You still keep posting these? You must be an idiot.

Implementation Speculation (5, Insightful)

cosm (1072588) | about 2 years ago | (#41988261)

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

Re:Implementation Speculation (4, Interesting)

complete loony (663508) | about 2 years ago | (#41988449)

Before a wifi device can transmit a packet, it must wait for a period of silence where no carrier is detected. Any device can simply keep transmitting to hog up the channel indefinitely.

This is the same idea behind the 802.11e burst mode, where you transmit a number of packets in quick succession, then ask the intended recipient to give you a bitmask of all the successfully delivered frames. Without pausing long enough for any other devices to jump in.

Re:Implementation Speculation (0)

Anonymous Coward | about 2 years ago | (#41989305)

Before a wifi device can transmit a packet, it must wait for a period of silence where no carrier is detected. Any device can simply keep transmitting to hog up the channel indefinitely.

Somebody mod this guy up, he's hit the nail on the head.

We're not talking about keeping track of each connected device's packet usage, we're talking about congestion on the wireless medium. When the AP detects congestion, most likely by simply watching the buffer size on the wireless interface, I'm guessing the AP steps in and intentionally hogs the channel until the clients STFU. The clients, also running the same protocol, would see the AP yelling at everyone to STFU, and stop trying to transmit until the AP tells that client specifically that it can take its turn. Once the congestion clears, the AP would then announce to the clients to resume normal operation.

It's hard to say exactly what they're doing, because this article is just an announcement that there is going to be an announcement about the details of the protocol. Once they chip loose with the details we'll be able to make a better determination if this will end up being a good protocol to adopt as a standard.
The problem I foresee is how to deal with rogue clients which aren't playing nice on the spectrum.

Re:Implementation Speculation (1)

complete loony (663508) | about 2 years ago | (#41989793)

Yeah, that's basically what I was thinking.

Most of the time all wifi clients want to talk to the network behind the AP, meaning that the AP should use a disproportionate share of the available airtime. So it stands to reason that the AP should bias its transmit priority or enter a kind of burst mode whenever its transmit queue starts to fill up.

Anyway, here's a little more info for people who haven't read the spec's for 802.11. When a station wants to send a frame, it first waits for a DIFS interval (28us) with no carrier detected, then picks a back off counter from 0-31 and waits for that many SIFS intervals (9us) to elapse. If there's still no-one transmitting, the radio will flip from receive to transmit mode and attempt to send a frame. If the back off fails, the upper limit will rise exponentially up to a limit of 255.

So if an AP wants to increase its priority in a graceful manner, it could simply choose a lower back off counter. Even if the other devices in the network are increasing theirs due to congestion. And after sending a single frame, instead of waiting for another DIFS + back off interval, it only has to wait for a single SIFS interval before transmitting. If every other device on the network is following the spec, they should still hear the transmitted frame.

Re:Implementation Speculation (2)

egcagrac0 (1410377) | about 2 years ago | (#41989283)

Given the name, I speculate that this software does a barrel roll periodically.

Another dumb summary (1)

oldhack (1037484) | about 2 years ago | (#41988269)

The described scheme ( blah blah "priority mode" blah blah) addresses the described problem ( congested channel ) not at all.

Coded TCP ? (3, Interesting)

bug1 (96678) | about 2 years ago | (#41988273)

Is this the same as last months "breakthrough" technology described in the MIT technology review.
http://www.technologyreview.com/news/429722/a-bandwidth-breakthrough [technologyreview.com]

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.

Re:Coded TCP ? (1)

timeOday (582209) | about 2 years ago | (#41988317)

Is this the same as last months "breakthrough" technology described in the MIT technology review.

Since it is completely different, and originates from a different group at a different university, I would guess, no.

Re:Coded TCP ? (4, Informative)

Dan East (318230) | about 2 years ago | (#41988349)

No, the MIT scheme is a formal protocol which requires both the access point and the client devices to work together. The client is able to "fill in" missing data, because the data itself is expressed in a computational manner that allows the client to perform calculations and solve for missing data.

What the NC group has done is simply made access points more assertive and "take control" of a channel by ignoring the fact that other devices are transmitting and talking over top of them. That scheme is applied when a backlog of data occurs, and assuming that most clients are consumers of data, it makes sense to push out cached data instead of wasting time listening to clients make additional data requests. Part of the reason this would work is that access points are optimally located in a given coverage area, they use higher gain antennas, and don't worry about reducing power to conserve batteries and the like, which allows them to "talk over" your typical client data consuming device.

Re:Coded TCP ? (2)

RatherBeAnonymous (1812866) | about 2 years ago | (#41989053)

No, the MIT scheme is a formal protocol which requires both the access point and the client devices to work together. The client is able to "fill in" missing data, because the data itself is expressed in a computational manner that allows the client to perform calculations and solve for missing data.

I have not read the article on the MIT protocol, but it doesn't sound like it will work in the real world any time soon. There is no way I can expect the first generation iPads, Android 1.x phones, Kindles, Nooks, netbooks, etc. that people bring to my network to support a new protocol, even if the devices do have enough processing horsepower to do the calculations.

What the NC group has done is simply made access points more assertive and "take control" of a channel by ignoring the fact that other devices are transmitting and talking over top of them.

When two transmitters talk simultaneously it causes a collision. Normally when a collision is detected the transmitting parties back off and stay silent for a random amount of time before retransmitting. The access points could be programmed to cheat and simply retransmit immediately, but that would violate the 802.11a/b/g protocols. An access point could just keep broadcasting and hope the receiver can sort out the signal. It might work if the interfering radio source is on the opposite side of the access point, but that can not be guaranteed.

That scheme is applied when a backlog of data occurs, and assuming that most clients are consumers of data, it makes sense to push out cached data instead of wasting time listening to clients make additional data requests.

A burst mode makes sense to prioritize clients that are waiting for larger amounts of data. But the higher tier wireless vendors have elected to use what they call "air time fairness" to give each client more democratic access to the available bandwidth. It might mean that every client gets 1 to 2 Mb, but a little bit of bandwidth to everybody is better that letting one or two clients hog the spectrum and force the remainder to disconnect.

Part of the reason this would work is that access points are optimally located in a given coverage area, they use higher gain antennas, and don't worry about reducing power to conserve batteries and the like, which allows them to "talk over" your typical client data consuming device.

There are two reasons I am skeptical on this.

Firstly, the 2.4GHz and 5GHz spectrums are unlicensed and there is a hard cap on transmitter power. That power level is easily attained by laptops. Access points do have better antennas than mobile devices, and higher quality access points will use some interesting beam-forming techniques or directional antennas to boost transmission in a desired direction. However, if the interference source is 2 feet away from the intended signal recipient, the access point will not be able to "talk over" the noise. That is actually more the norm in a business or educational setting. The access points are on the ceiling tens of feet away, and the client devices are surrounded by other client devices competing with them for bandwidth. Also, with the way TCP works, if a packet is corrupted early in a data stream, all the data after it may have to be retransmitted.

Secondly, reasonably designed wireless networks operate at as low a power as possible to keep the wireless collision domains as small as is practical. You don't want access points blasting out signal. I was chatting with a friend recently, a wireless engineer with 30+ years in the business, who related the story of a hospital where the wireless network was simply unusable. He spotted the problem within 10 minutes. The original installer had set every access point to max transmission power, so on the first floor he could see access points on the 5th floor. A couple days work of turning town the transmitter power and relocating a few access points fixed the network. Realistically, if a location is expected to see upwards of 20 clients, the better solution is to install more access points, preferably dual band. Because, while 802.11b/g can co-locate 3 access points without them interfering with each other, 802.11a can handle about two dozen non-overlapping channels.

Re:Coded TCP ? (0)

Anonymous Coward | about 2 years ago | (#41990503)

If this is a formal protocol, where's the documentation? This is BS sales talk until there is any actual data.

A good portion of our enterprise challenge is co-channel interference and the ever so popular hidden neighbors. Telling us there is a new magic bullet that is amazingly awesome and will be presented at a future conference just reeks of sales buzz for vaporware. We have seen it too many times.

I especially like the software only and and only at the AP parts of the magic beans. Until there's a formal protocol doc, I call *ahem* fairy tale.

Re:Coded TCP ? (1)

WaffleMonster (969671) | about 2 years ago | (#41988377)

Is this the same as last months "breakthrough" technology described in the MIT technology review.

It is the same in the sense someone has claimed they invented something new with spectacular results when the concepts are already well known and deployed in production.

How many queuing discplines are there that would do the same thing and without the side effect of skewing send side?

Re:Coded TCP ? (0)

Anonymous Coward | about 2 years ago | (#41988413)

how is it secret? It's been published in INFOCOM.

Re:Coded TCP ? (0)

Anonymous Coward | about 2 years ago | (#41990189)

You did not get the idea of network coding. Read up on it, it's interesting (and can do much much more than old-school Forward Error Correction can).

Re:Coded TCP ? (0)

Anonymous Coward | about 2 years ago | (#41990653)

neither hamming or FEC, it is erasure codes and is much lighter weight in processing at the expense of being more intrusive (in this implementation) than either. If you went ahead with the MIT scheme you would have a very robust network that could handle almost infinite packet loss, something that typical FEC schemes cannot do. But what does this have to do with the OP which is a queue management scheme, not an error correcting solution.

Combine it with this method from an earlier story (2)

apn_k (938000) | about 2 years ago | (#41988293)

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 [slashdot.org]

Re:Combine it with this method from an earlier sto (1)

Scarred Intellect (1648867) | about 2 years ago | (#41988725)

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 [slashdot.org]

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?

Re:Combine it with this method from an earlier sto (1)

gl4ss (559668) | about 2 years ago | (#41989277)

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.

Re:Combine it with this method from an earlier sto (0)

Anonymous Coward | about 2 years ago | (#41989389)

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 [slashdot.org]

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.

Stanford has done something similar (0)

Anonymous Coward | about 2 years ago | (#41988303)

I do not believe its vaporware

http://sing.stanford.edu/fullduplex/
http://www.kumunetworks.com/

Re:Stanford has done something similar (0)

Anonymous Coward | about 2 years ago | (#41988315)

Here is another link with a little more detail about the Stanford WiFi project

http://snsg.stanford.edu/projects/picasso/

Re:Stanford has done something similar (1)

egcagrac0 (1410377) | about 2 years ago | (#41989467)

Pretty sure that's not the same as an access point software update - full duplex RF requires some hardware changes as well.

Data consumers (5, Informative)

Dan East (318230) | about 2 years ago | (#41988305)

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.

Re:Data consumers (1)

Bruce Perens (3872) | about 2 years ago | (#41988697)

If the entire network end-to-end mitigated the present bufferbloat issues, you would not need this. It's only because a local AP gets too-full queues that this problem happens.

Re:Data consumers (1)

AmiMoJo (196126) | about 2 years ago | (#41989491)

Also someone will release a modified firmware that puts your router into shouty mode where it hogs all the bandwidth.

Re:Data consumers (0)

Anonymous Coward | about 2 years ago | (#41990835)

Not so much that, but unless you allow point to point traffic (is that even an option outside of ad-hoc mode?), the access point will be the choking point for all wireless data.

Even if you have ten computers doing equal internet communications with 1:1 upload:download ratio, you will still have each computer sending 5 percent of the data, and the access point sending 50% of the data. Even for an individual computer, it does make sense to get all the data that are ready for you, before sending more. Especially when the buffers are full, and sending more is just going to be dropped anyway.

Well... (1)

flyerbri (1519371) | about 2 years ago | (#41988367)

Well maybe the congestion is because the new wifi protocol has a cold? It is a newborn, after all, and more susceptible to colds!

Short description sounds a bit like DAMA (4, Interesting)

Xonea (637183) | about 2 years ago | (#41988487)

Like it was/is sometimes used in ham-radio packet radio or in satellite communitation.

http://en.wikipedia.org/wiki/Demand_Assigned_Multiple_Access [wikipedia.org]

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.

Re:Short description sounds a bit like DAMA (0)

Anonymous Coward | about 2 years ago | (#41990941)

Ubiquiti has done something like this with AirMax. It's changes WIFI access control from CSMA to TDMA. In order for this to work the clients need new firmware also.

congestion control (1)

Niobe (941496) | about 2 years ago | (#41988517)

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.

anal retentive here (1)

Black Parrot (19622) | about 2 years ago | (#41988607)

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?

Re:anal retentive here (1)

mdenham (747985) | about 2 years ago | (#41988681)

A jump from 900kbps ("around 1Mbps") to 7200kbps ("around 7Mbps") is very much a 700% increase.

The problem is a lack of significant figures here, which means that the "around 1Mbps to around 7Mbps" increase could be anywhere from as low as ~333% (1.5Mbps to 6.5Mbps) to as high as 1400% (0.5Mbps to 7.5Mbps).

This response has been brought to you by the -pedantic switch. Have a nice day!

Re:anal retentive here (1)

RatherBeAnonymous (1812866) | about 2 years ago | (#41989115)

The trouble is that the English language is vague. If I say something increased by 100% I clearly mean that it doubled. So, if 1 plus 100% equals 2, then 1 plus 600% is 7.

However, 2 is 200% of 1, just as 7 is 700% of 1.

To be more specific, the summary should read "boosting the throughput of busy WiFi networks by up to 7 times", or "boosting the throughput of busy WiFi networks by up to 700% of previous throughput"

700% faster (0)

Anonymous Coward | about 2 years ago | (#41988645)

Marge : Does anybody need that much porno?
Homer : Uuh-huuh-uuuh, 700%

Dubious claims in summary and TFA (2)

Grieviant (1598761) | about 2 years ago | (#41988851)

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.

Re:Dubious claims in summary and TFA (1)

ThatsMyNick (2004126) | about 2 years ago | (#41989013)

Overall throughput is increased by 700%. How it affects your depends on your usage pattern and your bandwidth requirements.

Re:Dubious claims in summary and TFA (1)

complete loony (663508) | about 2 years ago | (#41989901)

The main issue with the standard, is that access points are considered equal peers to the other devices on the network, and all devices should back off if the wifi medium is congested. But if everyone is fetching data from the internet and not from each other, the access point should be transmitting more than anyone else. Plus if we're talking TCP streams, which is likely, those clients are likely to be asking for re-transmissions. This will only make the problem worse, as the AP now has even more packets to deliver.

If the AP instead just keeps talking, preventing other wifi devices from getting a word in edgeways, it can clear any backlog quickly *and* make more efficient use of the available bandwidth.

Picture a dinner party conversation. Everyone is ultra polite, waiting for long periods of silence before saying something. And stopping if two people talk at the same time. In this case very few words are actually said. But the loud mouth at the table with no manners? When he's got something to say, he just keeps talking without pausing for breath. Everyone else is too polite to but in, and overall more words are spoken.

WiFi Breakthroughs! (0)

Anonymous Coward | about 2 years ago | (#41988873)

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!

Sorry, can't have it. (0)

Anonymous Coward | about 2 years ago | (#41989535)

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

No such thing as a free lunch (4, Insightful)

L4t3r4lu5 (1216702) | about 2 years ago | (#41989599)

... [T]he breakthrough is purely software-based, meaning it could be rolled out to existing WiFi networks relatively easily.

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

Re:No such thing as a free lunch (0)

Anonymous Coward | about 2 years ago | (#41990667)

Wow, feeling a bit like a guy who needs a new fridge in the breakroom are we?

Re:No such thing as a free lunch (1)

L4t3r4lu5 (1216702) | about 2 years ago | (#41991271)

Wow, feeling a bit like a guy who needs a new fridge in the breakroom are we?

Breaks in which to enjoy a break room would be a start.

Works for one day (0)

Anonymous Coward | about 2 years ago | (#41989615)

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.

How about a much simpler solution (2)

Viol8 (599362) | about 2 years ago | (#41989859)

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.

Re:How about a much simpler solution (1)

ChunderDownunder (709234) | about 2 years ago | (#41990085)

And what % of homes are wired up?

A friend of mine had about 20m of coax circumnavigating his rented home and had to apologise when the LAN went down because his gf had tripped over a cable, again.

Re:How about a much simpler solution (1)

Viol8 (599362) | about 2 years ago | (#41990127)

Why do they need to be wired up? Put the computer near the router FFS. Unless you live in a 20 bedroom mansion whats the problem?

Re:How about a much simpler solution (0)

Anonymous Coward | about 2 years ago | (#41991603)

"Put THE computer near the router" (emphasis mine)

This is 2012.
DVR's, computers in multiple rooms (bedrooms, kitchens, offices, bathrooms???), surveillance systems on dedicated computers, net appliances, game consoles, etc...

If we all lived in a brand-new construction with ethernet to every room, perhaps we could get by with minimal wireless, but we don't all have that luxury. ironically, the 20 bedroom mansion probably DOES have ethernet to every room (and would need multiple wireless access points anyway).

The rest of us live in an imperfect setting, and use multiple computing devices.

Unless you're in a studio apartment or the router in your mom's house happens to be in the basement where you want to put your computer... there are many many reasons for most of us to use wireless.

Re:How about a much simpler solution (0)

Anonymous Coward | about 2 years ago | (#41990601)

And what % of homes are wired up?

A friend of mine had about 20m of coax circumnavigating his rented home and had to apologise when the LAN went down because his gf had tripped over a cable, again.

Coax?!?!?!?

Pillaging ... (0)

Anonymous Coward | about 2 years ago | (#41989881)

Que an 'allways on' high-priority mode -hack (pushing the neighbours connections off-line) in 3 ... 2... 1...

dynamic QoS (1)

soldack (48581) | about 2 years ago | (#41991025)

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?

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?