What horrors lurk in the future: Networks without sysadmins

'We need either to enhance the protocols themselves, or cut them out somehow'

The Register: In a world neither dominated by the internet nor was routing owned by Cisco, people thinking about how to design stacks would criticize TCP/IP because it only addresses individual hosts. “My protocol can address applications,” some would say.

We look at how the world has progressed to virtualized instances, and per-application addressing and routing looks possible – but in the data center that looks like a knotty problem, getting stuff routed from application to application without the routing being the bottleneck.

Retana: It's very interesting. TCP and IP were supposed to be in the middle of everything. Now we see an evolution – everything runs over [HTTP] port 80, so all the applications use TCP, and now it's hard to do anything with them. It's getting ugly. And, of course, people use [HTTPS] port 443, and assume now it's secure.

We see things moving up the stack, where there's more application-level policy, but it's harder to manage at the network level. To look at what's going on, to be able to better route in the data centre, what we really want to do is to follow the application's traffic flow.

That's why there's a lot of focus on software-defined networks, our application-centric infrastructure, and other solutions, to [optimize] for application-specific flows.

The data center is one place where you can do that. You know, or you should know, what your application traffic flows are like. In the rest of the world, you can't.

The Register: Imagine that it's the future. We've got rid of IPv4, we have a huge address space, we could give every individual application its own IPv6 address. Would that help?

Retana: Sure, but there are many possibilities. The thing with IPv6 is that we can interpret it in different ways. Instead of using it just as an end station address, I can interpret it as an end station with an application, or an instance of an application.

Routing, as it is today, is destination-based routing, so if we [use a reference to] an application as the address itself, now we're going to route to that software. What we still need to look at is the behavior of the flow.

What do I need in terms of quality of service, in terms of delay, those sorts of things?

Because there are many ways, with so many paths, to get from here to there. I could go up the tree, and back down, maybe that's OK, or for some applications maybe that's not OK.

The Register: We might have to go horizontally because we absolutely need low latency?

Retana: And other applications don't need that. Routing based on the destination may still need some more information: it's not just looking at the address, to me it's other characteristics.

Routing protocols don't really understand that a path is or isn't congested – we need either to enhance the protocols themselves, or cut them out somehow.

The Register: Find some way for the route protocol to say “we're both in the same data center, and the shortest way is on that link, if it's congested go the other way.”

Retana: Exactly. Those things we need to better incorporate. And some of the protocols have mechanisms to look at delays, things like that – but they haven't been used a lot because in the past some of them have experienced instability: I see a congested link, I switch everything to the other side, now the other link is congested, I switch back.

The Register: Route flapping.

Retana: Right – we don't want that. We need a better way of understanding [the network]. A distributed routing protocol is a very nice thing, but it can be very complicated to coordinate. Everyone making their own decisions, and everyone is coordinating how they're going to use the resources.

You need some type of balance.

The Register: And you want some way to confine that, so that things that break only affect their own domain?

Retana: A break shouldn't affect everything else – it should be contained to the rack, or the data centre. Isolating failures is good network design. You need evolution in some of these protocols, or help – a policy controller that oversees and gives hints on what is the better course of action.

The Register: What are the working groups people should be watching for the interesting stuff?

Retana: SIDR – the Secure Inter-Domain Routing working group – they're defining world-changing things. To me, some of the most interesting problems we're trying to solve are the ones that seem like small problems, but could have big repercussions.

Homenet – the way they're defining a home network is multiple gateways, with multiple networks inside, and discovering how to orchestrate inside the home. Now, a home like that is a huge home, but in reality what they're looking at is “how do I auto-configure my network? How does the network automatically do things?”

And not just for a home: why not in a small branch office, and why not in the core of the enterprise? Or the service provider? There's work on autonomic networking, self-configuring, self-healing, self-optimizing. The network does everything by itself.

Today, you configure routers, borders and policies manually. They say the network could be designed to “have intent” – and that could have repercussions in making it simpler and making it heal, which is a big thing. ®