Achieving the Best Performance with O365 for Backhaul Traffic

Blanco Lam

Microsoft network connectivity principles

At the Microsoft Ignite conference last year, Microsoft presented the four network connectivity principles for Office 365. The key goal behind these connectivity principles is to ensure the best possible end-user experience when connecting to O365.

One of the recommended principles from Microsoft is to avoid backhaul traffic and allow direct breakout (otherwise known as “direct Internet access” or “local egress”) from the branch. The idea behind direct breakout is that the O365 traffic can enter Microsoft’s backbone as quickly as possible without needing to backhaul the traffic to a central location. As you can see from the graphic below, the red dotted line is the backhaul traffic while the green line is direct breakout.

direct to net

From a routing perspective, this approach makes perfect sense. I’ve spoken to many enterprise architects and all of them understand  this design principle. Yet, a large percentage of them are unable to implement this design in the foreseeable future. The reason? The change in security posture and the cost associated with implementing such a change.

Legacy network

For the past two decades, enterprise customers adopted a well-known hub-and-spoke or regional hub-and-spoke topology for Internet access. Typically, there is a heavy-duty security stack at the hub consisting of firewalls, IDS, IPS …etc. Any Internet-bound traffic from the branch offices must traverse this security stack. For example, Singapore or Hong Kong may act as the Asia Pacific regional hubs and all Internet traffic from the Asia Pacific region are backhauled to those regional hubs.

When migrating to a direct breakout model, it is imperative to maintain the same level of security. However, in order achieve this, it requires a significant redesign of the network that often includes a mini-security stack at each branch location. This in turn means that it’s expensive to deploy, complicated to manage, and perhaps the most important of all, an increase in attack vector.

For customers who are already considering SD-WAN, the change in security posture should already be factored into the design. However, not all customers are ready or want to embrace SD-WAN at this stage and yet the migration to O365 is happening right now. This presents an interesting dilemma: how does IT ensure good end-user performance without modifying the security posture?

SteelHead delivers the best performance

This is where the SteelHead product allows you to have your cake and eat it too. Let me share the results of some tests that I ran from our Singapore office. We have a 50Mbps circuit from our Singapore office and I’ve backhauled the traffic to our San Francisco headquarters hence the round trip latency was about 230ms. The test was a simple download of a 158MB PowerPoint document from my OneDrive folder. I also ran a test to gauge the performance of a direct breakout and the latency was only 5ms to the Microsoft front-end server.

test results

As you can see from the results, it took 111s to download the file in a typical backhaul situation. With optimization, SteelHead was able to reduce this to 39s on the first transfer and 24s on subsequent transfer. As a point of comparison, it took 35s to download the file with direct breakout. This proves that SteelHead was able to deliver comparable result as direct breakout despite the much higher WAN latency. However, the most important point is that the security posture remains the same as before.

So while I do support this network connectivity principle, I’m also aware that many customers are not ready to take this leap just yet. For those customers, we have a proven solution that would ensure the best performance when connecting for O365 for backhaul traffic.

No Responses to “Achieving the Best Performance with O365 for Backhaul Traffic”

Leave a Reply

Your email address will not be published. Required fields are marked *