Secondary Navigation

Primary Navigation

Google gives its network a boost with Espresso SDN architecture

By Tony Chan

Google has taken the wraps of a new software defined networking feature that promises faster, more available and cost effective access over the public internet to its cloud services. The new platform, codenamed Espresso, is described as a “peering edge architecture” that changes “the way traffic is directed at the peering edge, delivering unprecedented scale, flexibility and efficiency.” According to a corporate blog post by Google Fellow Amin Vahdat and Google engineer Bikash Koley, Espresso has been in production for over 2 years and routes 20% of the company’s total traffic to the internet – a number which is growing.

The role of Espresso is to address the complex traffic routing that is required to support the company’s applications such as real time voice search. “Answering the question ‘What’s the latest news?’ with Google Assistant requires a fast, low-latency connection from a user’s device to the edge of Google’s network, and from the edge of our network to one of our datacentres. Once inside a datacentre, hundreds – or even thousands – of individual servers must consult vast amounts of data to score the mapping of an audio recording to possible phrases in one of many languages and dialects,” the authors explained.

“The resulting phrase is then passed to another cluster to perform a web search, consulting a real-time index of internet content. The results are then gathered, scored and returned to the edge of Google’s network back to the end user.” “Answering queries in real-time involves coordinating dozens of internet routers and thousands of computers across the globe, often in the space of less than a second!

Further, the system must scale to a worldwide audience that generates thousands of queries every second.” Espresso is the latest component in Google’s attempts to optimise the performance of such applications, and complements Google’s existing software defined networking initiatives. These comprise Jupiter, which addresses interconnections inside datacentre; B4, which supports inter-datacentre connections; and Andromeda, a network function virtualisation stack supporting Google-native applications in the Google Cloud. “Early on, we realised that the network we needed to support our services did not exist and could not be bought. Hence, over the past 10+ years, we set out to the fill in the required pieces in-house,” they said.

“Our fundamental design philosophy is that the network should be treated as a large-scale distributed system and leverage the same control infrastructure we developed for Google’s compute and storage systems.” With Espresso, software defined capabilities are extended all the way to the peering edge of Google’s network, which connects to ISPs at 70 metros.

According to Google, Espresso delivers two key pieces of innovation: it allows Google to dynamically choose network paths to serve end points, and it centralises path control and management. “Rather than pick a static point to connect users simply based on their IP address (or worse, the IP address of their DNS resolver), we dynamically choose the best point and rebalance our traffic based on actual performance data.

“Similarly, we are able to react in real-time to failures and congestion both within our network and in the public internet,” they said. “Second, we separate the logic and control of traffic management from the confines of individual router ‘boxes’. Rather than relying on thousands of individual routers to manage and learn from packet streams, we push the functionality to a distributed system that extracts the aggregate information. We leverage our large-scale computing infrastructure and signals from the application itself to learn how individual flows are performing, as determined by the end user’s perception of quality.”