SEPTEMBER 5, 2019

Ever since she joined AT&T as a networking researcher in 1996, Jennifer Rexford has been on a mission to make networks more programmable. Frustrated by the lock commercial vendors had over her ability to innovate, she’s worked on many of the key projects designed to shift power to network designers and operators. She co-edited an early paper on OpenFlow in 2008, and in 2014 co-founded the P4 Language Consortium, which is devoted to building open source programming languages networking practitioners can use to quickly adapt to emerging threats and opportunities to run their networks more quickly, safely and reliably. Rexford joined Princeton University’s Computer Science Department in 2005, co-wrote the 1993 book “She’s an Engineer? Princeton Alumnae Reflect” and was the winner of the ACM Grace Murray Hopper Award for outstanding young computer professional of the year for 2004.

We spoke to her about the impact programmability will have not only on networks and the companies that run them, but on the lives of the networking practitioners and professionals who are responsible for them. Here are edited excerpts from the conversation.  


Q: The early designers of the internet made it highly programmable at the endpoints, thereby unleashing the creativity of millions of programmers to invent applications and technologies to enhance the Net’s utility. Now, you say it’s time we made the innards of the internet programmable as well. Why?

Because the internet as we know it now is dumb. It’s the Homer Simpson of networks. It works, but it doesn’t work well. For example, if you want to block unwanted traffic before it reaches a recipient or if you want to send traffic on the least congested path, the network administrator needs visibility to run the network effectively, just as people running applications need the ends of the internet to be programmable. So my work is focused on giving better tools to the people who’ve been trying to hold the internet together with duct tape and baling wire.

Q: How would a programmable, self-driving network impact enterprise networking groups?

We’ve been deploying programmable networking equipment in Princeton’s campus network. It’s admittedly smaller than most enterprise networks, but our administrators are very interested in what the biggest traffic flows are, what traffic might be malicious, what are users doing that could be done in a better way, who are the heavy hitters on the network. They want to be able to drill down and understand what’s really happening.

In one case, they were able to figure out why some of our neuro-scientists who had data-sharing relationships with other universities for things like MRI data were getting really bad performance. Or we have this intrusion detection system, but when we go to faster links it can’t keep up. How can we use programmability to scale up our security defenses in other ways, and have more control over policy?

Or here’s another example. I just came from a meeting with the network team about how to provide security in a BYOD setting. What operating systems are all these devices running? Should we be concerned if someone is running a really old version of Windows that hasn’t been patched in a long time? Even though we don’t have any control over this host, it would be nice to be able to have a talk with John Smith about the fact that he’s running really old software—or maybe block some of his access.

Q: How far along is this project? And are your network administrators concerned about destabilizing the network?

It’s been in the last six months since we deployed a handful of programmable switches from Barefoot Networks. And you’re right: you don’t want to take some relatively new hardware and start using it in the operational network. So what we’re doing is running the traffic from the legacy equipment through the Barefoot switches, and running the analytics on it there. So if we fail, we’re not going to break anything—which is hugely important because we’re a bunch of academics and grad students who probably are not the best software developers you’ve ever met.

So for now, you can think of what we’re doing as a glorified packet monitor. The full vision is to not only passively monitor and analyze what’s going on, but to close the loop and actually use it to run the network. Ultimately, we’d like to be able to enforce a policy that says “if you’re running MS-DOS, you can’t access our network” or to give people a way to look more closely for spam coming from machines running a particular version of Windows and have the network automatically do it. But for now, we’re taking baby steps.

Q: Is this a useful model for enterprises to get started down the path to programmable networks?

Yes, I think it’s a good way to start. We’re able to provide useful operational data to the network administrators, and build confidence that this might ultimately be a safe and worthwhile way to run the network. Plus, it addresses a real problem. If you wanted to do these analytics without a programmable switch, you’d have to store the data somewhere and the volume would be tremendous.

Q: Who has been doing the innovation?

The early adopters were the really large cloud providers like Microsoft, Facebook, Google and Amazon. That’s not surprising, because the old equipment was really not designed for their needs. They had control of everything in their data centers except their networks, and they just found that irritating! They wanted to do the software themselves—because frankly, they could probably do a better job than the equipment vendors.

Plus, they wanted to innovate, so they could do better than their competitors. And if they had to go to their vendor to ask for a new feature, it was going to take two years, and then they’d have to test the feature for the vendor, and at the end of the day the vendor is going to roll it out to all of their competitors at the same time.

Ironically, having a language like P4 lets these companies innovate in a proprietary way—in secret, if you will. It wasn’t what we had in mind necessarily. After all, we’re academics. We are like, “Yay, let’s make everything open, let’s all share!” But this is how the world works. They had a unique use case, and they had a huge equipment spend and wanted commodity equipment they could program for their own needs.

Q: So what happens now? How does the work take off with enterprises?

Well, enterprises are typically slow to move. If you look at the early enterprise members of the Open Networking Foundation, it was mostly finance companies, which makes sense because they tend to be earlier adopters. But Intel’s acquisition of Barefoot means a large, mainstream chip company is going to be producing programmable switching chips.

I’d like to say one to two years, but I don’t think that’s accurate because it takes time to change equipment. But you don’t have to make the entire network programmable. Maybe just start with the border routers at the edge of the network, where you get the most ability to manage performance and security. That’s what we’re doing at Princeton.

Q: If you’re in networking, what would your elevator pitch be to get the CIO to support moving towards a programmable network?

I would think security analytics would be the killer app—in particular security analytics as you upgrade your networks because your existing [security systems] may not be able to scale up to the higher speeds. You have to have the network hardware anyway, so why force traffic to go through a separate security appliance that’s going to slow it down?

I don’t mean to imply that the whole security industry should move to the network—that’s certainly not the case. But programmability can help with things like intrusion detection, stopping denial-of-service attacks, and getting more context about the BYOD hosts that are connected to your network. That’s going to be important as companies bring in more IoT devices, which tend to be pretty impoverished [in terms of compute power and built-in security] and not programmable.

Q: So I get how programmability could help network administrators improve life for their customers. What about for the network administrators themselves? Will it improve their lives?

In general, better visibility is a win, because you know where to start when things go bump in the night—and you never know if you’re going to be able to figure out the answer.

And it will create career opportunities, if you know how to write code. You’ll be able to buy most of the software you need, but maybe there’s some unusual aspect to your network that requires some special innovation. In general, network administrators had to be high priests of a low religion. They had to master the idiosyncrasies of vendor specific interfaces and protocols. That’s a skill, and I don’t mean to devalue it. The people who do it well are magicians. But my hope is that the job of being a network administrator becomes a more direct one—and when your manager asks for some new capability, you won’t have to tell them it will take three years to do something that may be critical for your organization. It’s frustrating, because too often you can see why the person in charge would come to see the networking person as the weak link that’s holding back the entire IT team.

Q: I’m sure some network administrators hear “self-driving network” and think “oh boy, automation is going to take my job away.”

That’s a fair point. But first of all, self-driving network is now just an aspirational goal. We’re not particularly close to achieving it. And in the meantime, there’s a tremendous need for people that have software and networking expertise to help create the technologies to make this goal possible. And when that day arrives, companies will demand more of their networks than is possible today. It’s healthy for low-level functions to be automated, especially since higher-level functionality is what gives people more chances to innovate.

Q: Right. So let’s end on this different topic. Obviously, Facebook and other software companies have been under a great deal of pressure to address real societal human problems associated with the internet—digital addiction, election meddling, polarization of society. You never read about what networking technologists are or could be doing. What role could they have?

First of all, I should point out that networking technology, like other technologies, is dual-use. The same kind of programmability that I’ve been talking about could also be used by a country to do surveillance. So you have to have an ethical understanding of how the technology can be used. Plus, a lot of software is buggy. And when a network crashes, it’s game over. So I don’t know that we’ve done a great job as an industry in setting high enough standards for our software. We hear all the time about outages and attacks that happen because of bugs in networking software. As networking professionals, we need to be on the ball about this.

And finally, the decisions we make as networking technologists will really determine who gets to innovate and where. The programmable story is all about that.

Q: So would you like to see more hacktivism from networking professionals, as we’ve seen among app developers?

It’s a fabulous question, and I think programmability is key because it gets the juices flowing. Just to give an example, an undergraduate senior working with me this year did some work on encrypting IP addresses so that you could send traffic over a network you don’t trust—hiding their ability to know the ultimate destination. So yeah, I think people who have strong opinions on topics such as surveillance, censorship and net neutrality will increasingly have a hammer so they can play a role.