Network Latency and Outlook

Had a ticket at work about Outlook in online mode being slow when connecting to Office 365 from Singapore. They person who opened the ticket did a massive amount of work. interviewed users with spreadsheets, took screen shots, pings, provided a network diagram – all of the things. After looking at all of the things the answer was, super duper sadly, cool story bro by desgin.

The answer of by Desgin made me feel like a mega dick 5000 (MD5000). We found a number of great blog posts explaining why the base / best case latency was their root cause – https://blogs.technet.microsoft.com/neiljohn/2011/06/15/outlook-2010-network-latency-test-results/ – Then I felt compelled to do some math. What follows is the content of an email I sent out to my team after the math took possession of my brains.

Possed Kev Brain

TLDR – Outlook is slow from X region to Office 365 – Yup because science, distance, software and hardware say so.

More words || Customer says “Outlook in Singapore is slow when I don’t do things in Cached mode” – Gee ,cached mode access on the machine is measured in NS. Ping time from Singapore to North Carolina is measured in 100’s of MS. I wonder why one is faster then the other. When then Average ping from X region to data center is 200+ MS any call not using, cached mode will result in a less then perfect Outlook Experience

In situations like this it does not matter if fast retransmit, dropped packet, colours in netmon, ETC are seen in packet capture.. What matters is the base physics if how long it takes for the packets to move from point A to B back to A. The ONLY hope we can offer a customer in this situation is;

Move closer to the datacenter (setup an APAC site, or EMEA site, or Move to NC)
Cache the data closer with an Exchange Concentrator / caching node, or use Cached mode in Outlook.

That’s it. No other options are available for Outlook in Online mode to work better.

The ping time from SG3(Singapore Datacenter) to BL4 (North Carolina Datacenter) is literally because of science / physics / speed of light in vacuum / software and hardware limitations / and rouge anchors. In basic terms electrons travel near the speed of light over a wire, but they can only go so far before they fade. Every few hundred feet or miles those electrons need to be touched by a device and be repeated – The repeating and routing is where most of the latency comes from.

MATH WORDS — Warning there be math here.

186,000 – Speed of light is approx. 186,000 MPS
1MS = 0.001 seconds (actually a thousandth of a second, words are odd)
1,800 Miles Per MS – Light can effectively travel about 1,800 miles in 1ms
(10,000 Miles SG3 – BL3) * 2 — Singapore to Blue Ridge NC is about 10,000 direct arc over the world miles – maybe double that in packet switched network transatlantic cable miles.
20,000/1,800 = 12MS- 12MS is the fastest we can go one way per electron in pure travel time.
33,3000 Miles in fiber – Most of the travel time is over Fiber optic cable. Light in a fiber does not travel in a straight line. It bounces inside of the fiber in a wave form. Basic math for fiber is a refractive index or about 0.6 – Meaning our 20,000 miles is now about 33,333 Miles
+2ms per 1,100 miles each way- Fiber signal degrades and needs to be repeated every 50 miles or so, and it needs to be regenerated every 300 5-6 repeats. Each repeater and regenerator adds latency. Rule of thumb is about 5ms per 1000 miles.
+2ms per hop – Then you add network switches, time in routers, time in signal amplifiers, time repeaters, data processing at every layer of the OSI, packet filtering. OSI and packet processing things like; frame serialization, media linking, processor available at the node, packet queuing, QOS process – ETC are going to add a different number at each step along the path. Let’s make it simple and say 2MS per touch per node in the path.