We’ve heard about a lot of benefits driving SDNs, but this week we found about a new one of particular importance to anyone building multi-site networks: Google is using an SDN to improve its WAN investment by more than three times.
Network engineers play a bit of a cat-and-mouse game to get the most of out their WANs. Passing more data gets organizations a better return on their WAN investment, but passing too much data risks dropping packets, causing performance problems and impacting end-user response times. All of which is a reason good network design keeps link utilization under 50 percent utilization.
As organizations look at SDN, though, they’re able to radically improve on those numbers by controlling how data flows within the data center and between sites, at least that’s what it would seem from a conversation Google Principal Engineer Amin Vahdat had with John Dix. Google is an early adopter of OpenFlow, and is using the traffic engineering capabilities of SDNs to triple its WAN utilization:
“The state-of-the-art in the industry is to run your lines at 30% to 40% utilization, and we’re able to run our wide-area lines at close to 100% utilization, just through careful traffic engineering and prioritization,” Vahdat said in his discussion with Dix.
Normally running at line capacity is impossible because of random microbursts of traffic which often occur. To make matters worse, many monitoring and SLA tools quantify average loss rates, missing microburst entirely. Silver Peak has seen this in particular with customers, like Google, as they look to run video conferencing and other loss-sensitive applications between locations.
So how are they avoiding the issue?
“…we can protect the high-priority traffic in the case of failures with elastic traffic that doesn’t have any strict deadline for delivery,” says Vahdat, “We can also route around failed links using non-shortest path forwarding, again with the global view of network topology and dynamically changing communication characteristics.”
Chalk one up for SDNs. Next week we’ll look at some of the reasons SDNs are important to your network and the players driving the SDN change.