When you watch Skyfall with three fellow networking researchers, comments such as the following ensue:

"Why is the list of all agents on a single file, on a single laptop hard drive, and encrypted so weakly that it's crackable in less than a week?"

"Wait. How can you even trace someone after you strip the headers off the packet?"

"That's a CISCO switch in that data center! ... Huh? What terrible wiring. Where's the cooling system? Is that a data center built with raspberry pies?"

"I can see assembly code on that terminal."

"Who the hell plugs-in a terrorist's laptop to your security sensitive internal network?"

"From where does that little radio transmitter's antenna get that much power to transmit such a signal in the first place?"

I love being around fellow nerds.

This talk from Seth Godin deeply resonates with my thoughts about education.

My two least favourite things about my hometown are mosquitoes and mosquitoes.

A close third, would be load shedding. For those of you unfamiliar with the jargon, it's basically a daily state-wide planned powercut for saving unicorns. Or energy. Or something. I can't remember the details except that it's annoying. Especially that time it was scheduled to go off right in the middle of a Kung Fu Panda 2 airing on HBO. **Especially** when they seem to introduce the practice only when I'm home for vacations.

So, let's say you're suffering from acute internetaddictionitis and the load-shedding kicks-in, leaving you hanging half-way through the Gangam Style video on Youtube, and also leaving you in the not-so-pleasant company of a squadron of mosquitoes. What do you do? Since there's no such thing as negotiation when it comes to these miniature vampires, the only option is battle.

Now these aren't ordinary mosquitoes. These are mosquitoes that have been hardened in their craft through generations of exposure to mosquito repellents. I'm pretty sure that evolutionary processes have gifted them a gland that harvests these repellents and converts them into energy or some arthropod-adrenaline-equivalent.

That said, mankind has had to resort to modern science in order to forge a weapon capable of taking on Satan's pets. Behold! The constant-voltage-electro-plasma-weave-scepter-3000. Or, for the less scientifically inclined, the mosquito bat.

This is what Thor's hammer probably looked like

Those of you who're from less threatened corners of the known universe might find this piece of technology rather overwhelmingly difficult to understand. But here's how it functions. The device works with the wielder holding the charge button, and swinging the device at a mosquito-monster, which upon successful contact, will deliver a very satisfyingly awesome spark thingy to the target. Sometimes, the target ends up stuck in the metal mesh, causing the mosquito to burn with the rather unpleasant odour of a burning mosquito.

Whoever came up with this idea actually brought some fun into the endless and futile battle that routinely happens in most Indian households every evening.

Anyhow, my entrepreneurial instincts tell me that there is room here for improvements.

Enter gamification:

• Turn these bats into Internet capable devices that can connect over WiFi, 3G, 4G, Parle-G, anything.
• Users register their device(s) through an online account.
• The device keeps track of the number of mosquitoes you pwn, and updates a score on a central server.
• The more you kill, the more you gain experience.
• As you gain experience, you level up. All users start at Lvl 1: Militia, and progress their way through to Lvl 100: Zeussian Mosquito Centurion Overlord. With each experience level, unlock features on your bat, like the anti-anthropod-plasma-cannon, and the zappa-mosquito-fragmentation-grenade-launcher.
• Compete with friends, family, neighbours, or fellow countrymen to slay as many of these buggers as you can in mosquito zapping tournaments. Win exciting prizes!
• Profit.

See? No "???" in between.

Unlike other capitalistic endeavours, this one is purely driven by a social angle which can be summed up by three words, "Kill. All. Mosquitoes." At the end of the day, we empower people with this device, and get rid of mosquitoes at the same time. Problem solved.

Now to figure out how to solve the load-shedding problem.

Here's the command history on my laptop's Ubuntu 10.04 installation (it's been running for a year and a half now):

$: history|awk '{a[$2]++ } END{for(i in a){print a[i] " " i}}'|sort -rn|head -n 20

1030 cd

833 v

747 git

653 sudo

564 gc

537 vim

531 hdfs

357 ls

343 grep

265 rm

204 tshark

186 cp

182 ack-grep

143 cat

126 ping

114 hg

102 mv

95 find

94 ssh

93 ./waf

"v" is my alias for vim, and "gc" is my alias for "git commit". So here's the somewhat corrected list (I say somewhat because I have even more aliases which I use for git, which I'm not taking into account).

1370 vim

1311 git

1030 cd

653 sudo

531 hdfs

357 ls

343 grep

265 rm

204 tshark

186 cp

182 ack-grep

143 cat

126 ping

114 hg

102 mv

95 find

94 ssh

93 ./waf

I find it surprising that over the 4 months I hacked on KTHFS, the "hdfs" command made it to my top 10 list! Mercurial (hg) and waf are in there thanks to my ns-3 duties.

Oh well, now back to work.

I've been putting this off for a while, but I guess it's high time I blogged about my master's thesis project. The work is due to be presented at  SIGCOMM '12; we have a paper accepted at HotSDN '12, and an accepted demo for the main conference track. So here goes!

Motivation:

We consider the specific case of enterprise WLANs, which have a very diverse set of requirements. Typical enterprise WLAN deployments consist of access points (APs), WLAN controllers, management systems, and a set of network services like mobility managers, load balancers, dynamic channel reconfiguration systems, and mechanisms to enforce policies. Enterprise WLAN vendor solutions today span the entire stack, ranging from AP hardware, to the controllers, and the network services. Unfortunately, these systems are proprietary and closed-source, leading to vendor-lock in, and limited flexibility.

However, the software-defined networking paradigm, enabled greatly through the adoption of OpenFlow by different vendors, allows one to easily introduce new features into a network. One can now write "network applications", that can programmatically orchestrate the network, thus allowing for greater flexibility with the control plane.

That said, our research has focused on the following question: "What do we need to write network applications for enterprise WLANs?"

The short answer is that OpenFlow alone does not suffice, and that we need some additional plumbing to be able to write network applications that extend into the realm of the 802.11 MAC. Our aim is to come up with useful abstractions that allow a programmer to express typical enterprise WLAN services as network applications, without having to introduce any hardware or software modifications to the 802.11 client.

Light Virtual Access Points (LVAPs):

In a regular WiFi setting, the client associates with an AP on the basis of locally-made decisions. The infrastructure has limited control over the client's point of association to the network, and cannot instruct a client to handoff to another AP without subjecting the client to a handoff delay (which isn't a pleasant experience for the user). Additionally, every handoff involves state machine changes at the client, AP, and authentication server. We feel that it would be cumbersome (and error-prone) if the programmer of an enterprise WLAN network application were to handle these state machine changes every now and then. The essence of the problem is basically this: a client's association is defined by the mac address of the client's interface, and the mac address of the AP, both of which are physical devices, and of which only one is mobile. To overcome this, we introduce Light Virtual Access Points (LVAPs).

An LVAP is basically a per-client, virtual AP. Every time a client performs a probe scan, a central controller spawns an LVAP on a physical AP close to the client (an analogy would be to spawn a virtual machine on a physical server). The LVAP is what responds to the client's probe scan with a probe response. The client can then continue the regular 802.11 association handshake with the LVAP. Once this is done, we've now formed an association between a client device capable of mobility, and an LVAP. At this point, the client is only concerned with getting ACKs for the data frames it generates, and receiving beacons from its LVAP in a timely fashion. Just like virtual machines in a data center can be migrated to a different physical server, an LVAP can be migrated to another physical AP. If an LVAP is migrated to another physical AP fast enough such that it retains all the necessary state to maintain its associations, and the client continues to receive ACKs and beacon frames, then the client can continue transmitting data frames without having to perform a re-association. Thus, an LVAP migration gives you the effect of a handoff, without actually inducing a state machine change at the client, and if this is done fast enough, the client won't even notice any period of disconnectivity. This works because the client only cares about the responses it gets from an AP (identified by a BSSID), and is oblivious to the actual physical radio that is generating these responses. LVAPs thus decouple the association state of a WiFi link from the physical APs in the network. This setup makes clients see the same consistent virtual AP regardless of the actual physical AP the client is within range of.

We thus designed Odin, which uses the LVAP abstraction to design network applications. An advantage with using LVAPs is that the programmer always sees a consistent link between the client and the network, defined by the BSSID of the LVAP and the mac address of the client device.

Odin:

Odin's architecture comprises of a single master, and a set of agents that run on the APs. The master is implemented as an OpenFlow application on top of the awesome Floodlight controller from BigSwitch Networks. The agents are implemented using the Click Modular Router, and run on the APs. The APs run Open vSwitch so that OpenFlow rules can be installed at each AP as well (every LVAP has a set of OpenFlow rules attached to it, which enable faster mobility, and can potentially be used to do access control as well).  Odin applications run atop the master, and control the placement of LVAPs. For instance, a mobility manager would attempt to place the LVAPs as close to the client as possible, and a load balancer would move LVAPs between physical APs such that the APs have an even processing load. Applications written on top of Odin can be both reactive, and proactive. Reactive applications use a pub-sub mechanism to receive notifications for specific MAC layer events that they can subscribe to. Proactive applications merely run within a loop, cycling between sleeping and doing some work.

Current Status:

Odin is currently deployed in the Berlin Open Wireless Lab's (BOWL) indoor testbed, and is being used by some of our users. I for one, use Odin for my daily network access needs (oh the joy of dog fooding!).

On-going Work:

We're currently in the process of supporting authentication more cleanly, are aiming for larger deployments, looking at multiple-channel configurations, and are also trying to design new applications and abstractions for Odin. That's a *lot* of work indeed, but we're pretty excited about what we're building. :)

Code:

Odin is available as an open source project on Github. Patches and feedback are more than welcome!