Airtime Fairness – Part 1 – For the Enterprise Wireless LAN

Airtime Fairness – Part 1 – For the Enterprise Wireless LAN


In this video, I want to discuss Meru’s Airtime
Fairness solution. Airtime fairness obviously is a really critical component of any enterprise
wireless LAN that seeks to be a switch replacement and a wired replacement, because predictability
is crucial, and in order to achieve predictability in the presence of a shared medium where you
have different devices operating at different data rates and with different capabilities,
it is absolutely important to be able to essentially silo each device in terms of the amount of
airtime or resources that it uses. Now, 802.11 as a protocol is a MAC-layer protocol. It
is a contention based protocol, a CSMA/CA-based protocol, very similar to Ethernet where devices
uses some variant of binary-exponential back off, essentially a randomized back off in
order to access the channel. And once they access the channel, they transmit their frame
— one or more frames — and once they transmit these frames, they go back and start looking
for the channel when they have more to transmit. The interesting thing is that this contention,
as defined by the original 802.11 standard, is really on a per-packet basis. So just to
lay it out in terms of a timeline, this is how the time dimension, I’m showing it here.
You have some period of time where the channel was busy, and let’s assume you have a couple
of different transmitters. So you have station 1 and station 2. Both of them see that the
channel was busy at this point, and then once the channel becomes free, both of them wait
for a certain period of time. A companion video talks about sort of the actual protocol
videos. For the purpose of this video, it is important to understand that each of these
devices, once it waits for a certain period of time for the channel to be free, starts
counting down some back off value. Let’s say in this particular case, station 1 picked
the value of, what’s that? 4, 3, 2, 1. So it picks a value 4, and station 2 picked a
value of 5. So each of these devices started counting down, and at the end of four slots
station 1 saw the channel was free and therefore it started transmitting. During this period, station 2 had a back off
period of 1, therefore it couldn’t transmit, therefore it stops counting down. Station
1 wins its transmission. It transmits one frame, and then it’s intended the receiver
sends acknowledgement for it, so this is the data, and then station 1 continues. Essentially,
this entire phase starts again. So notice something really critical here. The first
thing is, this is a multiple access protocol. The second thing is that we created, or we
started afresh after each data transmission. So essentially it’s a memory-less system to
some extent. There’s actually some nuances to 802.11 that causes the system to have memory
because station 2 remembers its back off, we’ll get into that in a separate video, but
the point is the contention period is a memory-less system. After one transmission of data, the
whole process starts again. How long is this data frame? It’s irrelevant to starting this
process again. So notice that if you have station 1 that transmits at 1Mbps, and station
2 that’s transmitting at 300Mbps, they both contained, pretty much the same, at the end
of each data transmission. So what does this mean? This means unless you have some higher
level way of controlling the amount of time that station 1 and station 2 use, station
1 will overrun the network, because in terms of the contention, if they both use the same
parameters, station 1 will win approximately half the time and station 2 will win half
the time. When station 1 wins, it takes much longer — at least 300 times as long — to
transmit its frame as station 2. So if I just lay this out in terms of time, station 1,
station 2. Station 1, station 2. Notice the amount of data being sent might be exactly
the same, it’s just the amount of time taken by station 2 is far lower because it’s going
300 times as fast. So if you look at this, it’s pretty clear
that station 1 is actually dominating the airtime even though both of them are sending
the same number of packets. As a result, the entire network comes closer to 1 megabit than
300 megabits. So the point here is, in a network where different devices share the same medium
but translate at different data rates, there is a difference between packet level fairness
and time or resource level fairness, and the resource here, which is the common denominator,
is one of time. So Meru pioneered this concept of Airtime fairness wherein we are not just
trying to equalize packets — although of course there is a mode in our system that
allows us to do that — but in order to provide predictability, we equalize airtime. Station 1 and station 2 will get the same
amount of airtime. What station 1 does with its airtime is its problem. Station 2 gets
its airtime, what it does is its problem. So the idea is the following: we want to give
station 1, and then give a bucket of time for station 2, during which time because it’s
faster it can pump in a lot more frames. And then station 1, and then station 2, etc. So
notice that there are some situations where packet-level fairness are appropriate. There
are a lot of other situations where time-level fairness is appropriate. And it’s critical
to have a system that can support multiple modes. Meru supports all the modes, but this
airtime fairness or time-based fairness is our default mode because it leads to predictability.
Now the question is how we do it.

Leave a Reply

Your email address will not be published. Required fields are marked *