The 1993 acquisition of Crescendo was a life-changing moment for Cisco. It was the first of what would be many acquisitions, but it also brought a group of executives who would play major roles in the next 20 years — most notably the spin-in team, led by Mario Mazzola. That group of executives recently left the company.

Tom Esdall was part of that acquisition as a principal engineer. He's since become a Cisco fellow and the CTO of the Insieme business unit, the last of the spin-ins and the source of Cisco's Application-Centric Infrastructure (ACI).

He also doesn't talk to the press much. A conference appearance in 2013, when Insieme was still keeping its product a secret, was enough to warrant a headline.

Truth is, Esdall is a friendly guy who gets downright chatty over the right topics. In May, at the Open Networking User Group conference held at Intuit headquarters, Cisco offered up a chance to chat with Edsall. We sat outdoors under a patio umbrella near Intuit's modernistic artificial streams and chatted about his current job, the webscale revolution, and the rise of containers. Here's an excerpt:

How has ACI gone compared with your expectations before the spin-in?

Edsall: I learned a huge amount about policy and what it meant to be application-centric. Rather than just say that, what does it really mean? You know, I came from a networking background. I was hardcore Cisco. I was a founder at Crescendo.

So you go back a long time. You can do this blindfolded with chainsaws.

Edsall: Doing another network is not that interesting to me. It was part of the boredom of doing that, that was why I left Cisco to start Insieme. And then, later on, Cisco stepped in and funded us.

It's really, in some ways, humbling, because at a certain level you say, "You know what? The network's not even important." That's really what it comes down to, and I've said this in a number of talks. What's the most important thing in the data center? I asked it yesterday at an internal Cisco meeting with 300 sales engineers. And I get, "Oh, it's power." "It's servers." "It's this-and-that —" no. The most important thing is the application. If you didn't have applications, you wouldn't bother to connect the power to the network.

Actually, that's a little bit of a lie — it's the applications and it's the information. It's the applications that make the information useful to the business.

So, what I care about is: Did the application performance improve or not? What we've found in a number of cases is that maybe it makes sense to drop more packets. Clearly, dropping packets doesn't improve application performance by itself. But if we can more aggressively manage bandwidth by dropping packets, we can reduce latency, and the benefit of the reduced latency overcame the dis-benefit of dropping a packet. That's application-centric. That's what's important about SDN today, is having a place where you can express your intent.

I think that's where some of the competing solutions have missed the mark. They have used that interface to describe networks, and I want to describe what the application wants from the network.

A lot of this policy or intent work has happened in the open source realm. What's your take on that?

For the kinds of things that are done with SDN, and of course the whole compute model with VMs and containers, the standards bodies, in my opinion, are not nearly as relevant. The IETF, the IEEE — they matter but not as much. What has replaced them is the open source community. It's all about having it out there and having others accept it.

I'd agree with that. It's helped with the policy stuff. They didn't sit in a room for a year discussing what they were going to standardize over the next three years.

Edsall: You can imagine. And the thing about REST APIs and JSON is, even if I'm different from one of my competitors — if we're both doing the same kind of model, then to adapt to either one is very easy. That's why you see everyone pushing APIs, and the way we interact is through APIs, instead of through protocols.

Continued on Page 2.