Microsoft recently released a Proof of Concept (POC) for a new tool, the Office 365 Network Performance tool, that shows you the network latency to the nearest Office 365 service “front door” when you input a location. To quote Microsoft’s networking page:
End user connections are dynamically routed to the nearest Office 365 entry point by the Microsoft Global Network’s Distributed Service Front Door infrastructure, and traffic is then routed internally to data and service endpoints over Microsoft’s ultra-low latency high availability dark fiber.
Low network latency and reliability are the most significant factors that determine the quality of the end user experience between Office 365 clients and Office 365 front doors. Once you get into the Microsoft front door, access to a particular resource should be fast as you’re traversing the Microsoft Global Network that interconnects all of Microsoft’s datacenters, no matter where your actual data lives.
The primary goal in designing network access to Office 365 is to minimize latency by reducing the round-trip time (RTT) from your users machines to the Microsoft Global Network.
Location Based Geo Routing
One of the core components of Office 365 networking is its geographical DNS routing. That’s where getting you to the front door starts. This DNS load-balancing and proximity-based routing technique tries to get you to the “front-door” of Microsoft’s network with as little latency as possible. The new Office 365 network tool (it should really be called an “onboarding” tool as the URL would indicate), lets you test to see where the current GEO-routing is estimating its best efforts to get you to that front door.
A Work in Progress
When we ran the tool for the first time, it looked like there was still a bit of work to be done. We entered our current location (Boston, MA) and it returned the following:
Your network perimeter location is Lexington, MA, US.
Your current service front door location is London, GB and network latency is 214 ms.
This isn’t the right result for how our users route to Office 365. Its likely due to the early nature (POC) of the tool. Here’s a screenshot where they show us going through London when we should have gone through the Virginia area as they were suggesting.
UPDATE: We’ve rerun the tool and it is now correctly reporting a better service front-door – one that has much lower latency. Now, for the Boston, MA area, the on-boarding tool reports the correct front door of Boydton, VA with latency of approximately 30-40ms.
Boston, and the surrounding vicinities, through Comcast, generally route through Boston and then leverage high-speed fiber to New York, followed by quick access to Virginia datacenters and then into Microsoft’s msn.net, their global fiber network. You can see this by examining the network path performance for one of the CloudReady sensors that we run at our HQ.
If Office 365 load balancing were to route our traffic through to London then it would introduce quite a bit of latency.
A Little Bit of Crowd-sourcing Too
Exoprise loves crowd-sourced data as a way of helping make sense of metrics, network and SaaS quality through comparisons. The Microsoft Office 365 Network Onboarding tool attempts to crowd-source the data showing you performance relative to other Office 365 customers nearby. This is helpful to know if you are meeting or exceeding your network latency targets and how you rank against customers that are near you. We definitely approve of such crowd-sourced data!
Read these additional articles about Microsoft’s Global Network:
Lastly, Microsoft recommends keeping it simple when it comes to optimizing networking for Office 365 and Azure access by following a few key principles:
- Identify Office 365 network traffic
- Allow local branch egress of Office 365 network traffic to the internet from each location where users connect to Office 365
- Allow Office 365 traffic to bypass proxies and packet inspection devices