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

27 of 130 comments (clear)

  1. Best example of Vaporware I've heard in a while by madsci1016 · · Score: 2, Funny

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

    1. Re:Best example of Vaporware I've heard in a while by Anonymous Coward · · Score: 5, Informative

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

    2. Re:Best example of Vaporware I've heard in a while by MarcQuadra · · Score: 4, Insightful

      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.

      --
      "Sometimes, I think Trent just needs a cup of hot chocolate and a blankie." -Tori Amos on Nine Inch Nails
    3. Re:Best example of Vaporware I've heard in a while by NatasRevol · · Score: 2

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

      --
      There are two types of people in the world: Those who crave closure
    4. Re:Best example of Vaporware I've heard in a while by fsterman · · Score: 5, Informative

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

      --
      Is there anything better than clicking through Microsoft ads on Slashdot?
    5. Re:Best example of Vaporware I've heard in a while by icebike · · Score: 2

      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/

      --
      Sig Battery depleted. Reverting to safe mode.
    6. Re:Best example of Vaporware I've heard in a while by Anonymous Coward · · Score: 5, Informative

      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.

    7. Re:Best example of Vaporware I've heard in a while by jamesh · · Score: 3, Funny

      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!

    8. Re:Best example of Vaporware I've heard in a while by tattood · · Score: 3, Informative

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

      --
      WTB [sig], PST!!!
  2. Catchy name for an old idea? by Anonymous Coward · · Score: 5, Interesting

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

    1. Re:Catchy name for an old idea? by transporter_ii · · Score: 2

      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.

      --
      Doctors destroy health, lawyers destroy justice, universities destroy knowledge, religion destroys spirituality
  3. Implementation Speculation by cosm · · Score: 5, Insightful

    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
    1. Re:Implementation Speculation by complete+loony · · Score: 4, Interesting

      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.

      --
      09F91102 no, 455FE104 nope, F190A1E8 uh-uh, 7A5F8A09 that's not it, C87294CE no. Ah! 452F6E403CDF10714E41DFAA257D313F.
    2. Re:Implementation Speculation by egcagrac0 · · Score: 2

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

  4. Coded TCP ? by bug1 · · Score: 3, Interesting

    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.

    1. Re:Coded TCP ? by Dan+East · · Score: 4, Informative

      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.

      --
      Better known as 318230.
    2. Re:Coded TCP ? by RatherBeAnonymous · · Score: 2

      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 fe

  5. Combine it with this method from an earlier story by apn_k · · Score: 2
  6. Data consumers by Dan+East · · Score: 5, Informative

    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.
  7. Short description sounds a bit like DAMA by Xonea · · Score: 4, Interesting

    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.

  8. Re:Dammit! by Githaron · · Score: 4, Funny

    Idiot is a verb now?

  9. Re:Um... by Bruce+Perens · · Score: 3, Informative

    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.

  10. Re:Dammit! by Anonymous Coward · · Score: 5, Funny

    Idiot a fucking dictionary, noob.

  11. Re:Dammit! by Anonymous Coward · · Score: 2, Funny

    Idiot a fucking dictionary, noob.

    Fuck you and the horse you idioted in on!

  12. Dubious claims in summary and TFA by Grieviant · · Score: 2

    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.

  13. No such thing as a free lunch by L4t3r4lu5 · · Score: 4, Insightful

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

    --
    Finally had enough. Come see us over at https://soylentnews.org/
  14. How about a much simpler solution by Viol8 · · Score: 2

    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.