We had the opportunity to sit down for a chat with Murphy McCauley of ICSI and UC Berkeley and get his thoughts on the venerable NOX controller, as well as exciting work happening on POX, arguably an offspring of the original NOX project. NOX plays an important role in the evolution of SDN and OpenFlow and we felt it was important to ensure SDxCentral readers get a first-hand account of where the project is going.

SDxCentral: What do you do for your day job?

Murphy: “My primary job for the past couple of years has been doing research with the networking group at the International Computer Science Institute (ICSI) under Scott Shenker. I've also just become a grad student at UC Berkeley.”

SDxCentral: When and how did you get involved in SDN?

Murphy: “I was doing my undergrad at Northern Arizona University and made friends with one of my instructors who is also a friend of Martin Casado's. He introduced the two of us when Martin came to do a talk. This eventually led to an internship at Nicira in 2008. I've been involved with SDN at some level since then.”

SDxCentral: For a while, you were the only one fixing bugs and supporting the original NOX. What happened there with the rest of the folks?

Murphy: “Well, a lot of the serious users who were really engaged with the community went in their separate ways, and Nicira went in their own direction, of course. Some of the Stanford users switched to Beacon. Eventually, there were three of us (two of us at ICSI, one at Stanford), and then just the two of us at ICSI, etc. It just kind of happened that way.”

SNDCentral:  What's happening with NOX, NOX Destiny, NOX Zaku now?

Murphy: “Well, for starters, there's a major new version of NOX. This is the verity branch.  Amin Tootoonchian has done the heavy lifting on this based on work he's been doing over the past couple of years. It's cleaner, slimmer, and faster. On the down side, it drops a lot of components and Python support. We actually don't think that's a huge down side, but we recognize that it's a substantial departure and that it's not backwards compatible, so we haven't just killed off the older NOX entirely.  We now refer to the older branches like zaku and destiny as ‘NOX Classic.’

We don't really use NOX Classic at Berkeley or ICSI anymore, so they haven't seen much movement for a while, and it shows (they don't compile easily on recent versions of Ubuntu, for example). The code has been moved to github, so people are welcome to fork it and put in pull requests, which we'll review. But on the whole, I don't really suggest starting new projects with zaku or destiny unless you know what you are doing.  The amount of support we can offer is certainly diminished given that we're not active users of it anymore ourselves.”

SDxCentral: Why keep the NOX name instead of renaming the new version?

Murphy: “We kept the name NOX because while the new codebase is the most substantial change NOX has seen, it really is still NOX, just the next version. That said, we didn't want to just step all over the old NOX and relegate it to some arcane branches; we figure there may still be development or maintenance on it for existing projects that don't want to (or can't easily) switch to the newer codebase. We could have called the new one ‘NOX-Next-Gen’, but then we'd run the risk of having to call the next version ‘NOX-Next-Gen-Next-Gen,’ and you can only do that four or five times before it starts getting silly. What we really want to make clear is that as far as we're concerned, the new codebase is the way forward.”

SDxCentral: How does POX fit into the picture?

Murphy: “Well, POX came about in response to our own experience with NOX and with what we saw from other users. I think in part this stems from the fact that NOX started life as a product, but ended up being used a lot for research, and those two aren't the same.

For one thing, a lot of users were only really interested in Python, and NOX wasn't ideal for that. Just getting NOX built could be a bit of a challenge. The interface between the C++ and Python parts could be difficult to understand or extend. Python multithreading didn't work (which stopped one from using a fair number of libraries, for example). So POX was created to address that -- to make a framework that made it easier to write controllers in Python, and this really dovetails with the new NOX codebase. Compared to NOX Classic, POX makes it easier to write Python components, and the new NOX makes it easier to write C++ components. In both cases they generally come out with better performance.”

SDxCentral: What is your vision for POX and NOX?

Murphy: “I'd like to see POX continue to become a good platform for SDN research, academia, education, and experimentation. And at least for us, it's one of our tools for helping to explore the abstractions and applicability of SDN, so that will continue too.

For NOX, I am not quite as sure. We think it's a good starting point for writing some really fast controllers, but that mostly means designs which heavily rely on packet-in events, and we don't currently have too many plans in that direction. We also think it would be a good starting point for a solid C++ production controller, but again, that's not really our focus. We'll be interested to see what the community does with it.”

SDxCentral: So, who should use NOX, and who should use POX?

Murphy: “If you want an introduction to or to experiment with SDN on Mac OS, Windows, or Linux -- use POX. If you want to use SDN in the classroom or to prototype SDN projects -- use POX.  If you're doing academic research -- use POX.

If you want to build a system that's bound by controller performance or a finely engineered controller written in C++ -- start with NOX.”

SDxCentral:  Who's working on both projects today?

Murphy: "At the moment, Amin is the only one specifically working on them.  I'm officially taking a break, but I am intending to continue contributing.  For example, I'll be releasing the start of a web-based GUI sometime soon.  And a number of us at Berkeley and ICSI (myself included) use them as part of other projects fairly regularly and are willing to chase down problems and push in improvements as we're able.  I think the medium-term plan is for the Open Networking Lab to take a more active role."

SDxCentral: NOX has historically been the most popular controller of choice within the research and education community. Do you see that changing?

Murphy: “Possibly, depending on your needs. Our belief is that POX is generally the easier option. I mean, that's closer to POX's goals.

And, I know Floodlight is picking up a lot of steam here too, which makes sense. It's got good resources behind it, and certainly they have an active focus on production. If that's where your interests are (and not on the more academic side), then this makes sense.”

SDxCentral: What's your view on the multiple different controllers in the marketplace? Floodlight, Trema, NodeFlow, etc?

Murphy: “People have different reasons for getting involved with SDN. People want different things from it. Certainly it makes sense that different controllers evolve to suit these different motivations -- especially since it's still so early that we don't even know what all the uses for SDN are, much less which ones are real wins. It's a big space, and each of these controllers is a point in it. Even in fairly established domains such as web servers or programming languages, you end up with multiple players. So, I think it's a healthy thing and a good sign for SDN.”

SDxCentral:  What's your view on the Northbound API discussions?

Murphy: “I think discussions of the northbound API may have leapfrogged a bigger question: what is it an API for? That is to say, forget about the specifics of the interface: can anyone explain exactly what the controller is? Where, if anywhere is the clean line that separates the controller from the application?  If you have an answer to this, I think the actual API will just fall out. But, I think coming up with an answer about what a controller is that supports all the SDN applications we've thought of and all the ones we haven't thought of yet is a tall order. As I said, that's something our group at Berkeley works on. So, that sort of takes us back to my answer to the previous question: I think at least for the foreseeable future, we end up with multiple controllers that are best used to support different types of applications, with no single magic "SDN API" that works for all of them.

Ultimately, I think it's a bit premature to be talking APIs. People should write their applications, and if they can cleanly separate their application from a controller, then they've defined an API. Some of these will end up being more flexible or better designed or just more useful, and some winners will emerge. Those ones will get embraced. Really, I think we're already seeing this, for example with OpenStack Quantum. They are defined by the application, and controllers grow to support it.  I think this is a really practical way to go about it for now.”

SDxCentral: What's the number one thing the community can do to support you in your efforts?

Murphy: “Really engage the rest of the community. Do your development in a github fork, issue pull requests, submit bug reports, get on the mailing lists, get on the website; anything! I think there have been some instances where people haven't done this that have resulted in real missed opportunity on both sides. And, I *know* there have been some longstanding bugs that nobody ever told us about but we would have been happy to fix if we had been aware of them. Get involved!”