The network of the future might have to evolve from the network of today, but it has to evolve and not take root there. Google has consistently looked first at the future, in network terms in particular, and only then worry about linking the future back to the present. Their latest announced concept, Expresso, has been in use for a couple years now, and I hope that operators and vendors alike will learn some lessons from it.
“Early on, we realized that the network we needed to support our services did not exist and could not be bought.” That’s a Google quote from their blog on Expresso, and it’s absolutely profound. It’s first and foremost an indictment of the notion that the goal of evolution in networking is creating incremental, safe-feeling, change not facing the future. I want to sell something, and networking as it exists will constrain my ability to do that. Therefore, I will change networking. How many network operators could have and should have done that?
Expresso is an evolution of a concept that Google introduced to allow its data centers to be linked with a highly efficient SDN core while at the same time maintaining the look of an IP network. SDN allows for very deterministic traffic management and in its pure form it eliminates the adaptive routing that’s been a fixture of the Internet for ages. Google’s goal was to make its data-center-connect SDN network (B4) and its data center network SDN (Jupiter) work inside an abstraction, something that looked like an IP core network but wasn’t. Expresso is what does that.
A company like Google connects with a lot of the Internet; they say they peer with ISPs in over 70 metro areas. At this “peering surface” Google has to look like an IP network because the ISPs themselves don’t implement B4, they implement IP/BGP. What Expresso does is create a kind of abstract giant virtual BGP router around its entire peering surface, creating a core SDN network and data center structure inside. All of Google’s services appear to be peered with all its partners at each of the peering points. Inside, SDN links user traffic to services without a lot of intermediary router hops that generate latency. This is what makes it possible for Google to offer low-latency services like it’s “Hey, Google” voice assistant.
Expresso creates what’s effectively a two-tier Internet. The “slow lane” of the Internet is the stuff that’s based on IP end-to-end, and it might take a half-dozen hops to get through the BGP area in which a service is offered and be linked to the server that actually provides it. With Expresso, once you pass through the peering surface you’re in the SDN “fast lane”.
Expresso also does some “process caching” in effect. A user can be linked to the service point that offers the best performance without changing the IP address the user sees as the service URL. Think of it as providing services a “process IP address” that Google then maps to the best place to run that process.
Traffic management is based on the pure-SDN notion of centralization. There is no adaptive routing, no “convergence time” for the network to adapt to changing conditions. A central process makes route decisions based on a broad set of utilization, availability, and QoE metrics, and that same process coordinates traffic on every trunk, every route. The result is a very high level of utilization combined with very deterministic performance, a combination difficult to achieve in a real IP network except where utilization is held to 50% or so. In effect, Google doubles the capacity of its trunks.
Taken as a whole, Expresso demonstrates how SDN should have been considered, which is also how NFV should have been considered, and how everything should be. Google was goal-oriented, top-down, in their approach. That let Google define the way Expresso had to work based on how their B4 data center interconnect (DCI) worked, and how they wanted their services to work. What they came up with is abstraction, the notion of making a cooperative system of any given technology or set of technologies, look like a single virtual piece of a different technology. BGP in effect creates an “intent model” of an Internet area, inside which the property that’s visible is the property BGP makes visible. How the property is fulfilled is nobody’s business but Google’s.
Another interesting aspect of Expresso is that it could be pushed ‘way out toward the network edge. Google is already metro-peering. As access networks and operator metro infrastructure changes, it’s easy to see Expresso sitting right inside the access edge grabbing Google traffic and giving it the best possible performance in support of Google’s services. The further forward Expresso gets, the more useful it is because the more traditional inefficient, higher-latency, IP routing is displaced by SDN.
So suppose that you had an “Expresso Agent” right at the edge itself? Suppose you could tap off Google traffic and tunnel it right into B4? One of the lovely properties of an abstraction like the one Expresso creates is that it doesn’t have to be the only face that Google shows to the sun. You could take the same set of Google networks and features and push them through a custom SDN abstraction, one more aware of services and less location-specific. Could Google then define not only the core of the future, but the service edge of the future?
Perhaps, but promoting any new edge protocol would be a challenge in an age where all anyone knows about is IP. The big value Expresso reveals is the notion of the abstract proxy. You don’t have to proxy IP/BGP, you could proxy any convenient protocol with an Expresso-like approach. Stick Expresso-like technology in an edge router or an SD-WAN box and you can connect to anything you like inside. You can transform the way the network works while leaving the services intact.
That’s what operators need to be thinking about, particularly for things like 5G. Why wouldn’t the goals of 5G be best satisfied with an inside/outside Expresso model? Here we have something carrying an estimated 25% of all the traffic of the Internet, so it’s surely proved itself. We should have been paying more attention to Google all along, as I’ve said in prior blogs. We darn sure should be paying attention now.