How to Improve Your Network to Meet Microsoft Teams Requirements?
Originally posted on gsx.com
This entry is part of our series on Microsoft Teams Performance monitoring. In this article, we will check how you can improve your network in order to reach MS Teams requirements. Of course, before doing anything to improve your network, you should deploy Robot Users in your critical locations to see and understand the impact of the changes you want to implement on your end-user experience. You need to make sure that you’re not spending your time and money for very little to no results. For more information about how the Robot Users are providing you with end-user experience metrics, please read this article >>
Distance and Egress Point
To improve your network performance, you can first try to remove the impact of geographical distance. For example, do not use a European-based Office 365 tenant to connect users that are in Singapore. The Microsoft Network has over 160 Edge locations worldwide. Therefore, Microsoft highly recommends that your company sites and the Microsoft Edges are on the same continent and as close as they can be. You should also always have your users connecting directly to the Microsoft network as fast as they can. It means to ban any redirection to headquarter before breaking out to the internet. The Microsoft network will always be faster than your ISP to connect to your tenant. So, a user in Singapore should directly break out on the internet in Singapore connecting to a Microsoft Singapore tenant in order to minimize any possible latency. It provides examples, tests and results on how your network configuration impacts the overall network ability to handle Office 365 workloads.
Avoiding Unnecessary Infrastructure Layers
Connecting to the closest Microsoft Edge point is a good start but you also need to think about the entire path of the information from the Teams client to the Microsoft datacenter. The shorter the better.
It means that Microsoft recommends that you avoid using a company proxy before reaching out to the Internet. With the same philosophy, you should exclude Microsoft 365 URLs using PAC files to send Microsoft 365 to a firewall. Finally, you should prevent the use of a VPN tunnel. As you may know the Teams traffic is already encrypted with TLS and media workloads are encrypted with Secure Real Time Protocol. So, the use of a VPN will just add another encryption, additional network hops, and finally greatly affects the end-user performance increasing Jitter, packet loss and latency.
Sites Education and Optimization
User education is important. It is important to tell users in advance what they can expect, what kind of issues they can encounter and the process you have in place to address these issues. People are usually less likely to complain if they know in advance what can be expected. Also, you can explain the performance they lose they gain in flexibility (working from anywhere, being connected to Office 365 wherever they are, etc.).It is also important to educate users on best practices and provide them with certified equipment. A very simple best practice, for example, is to make sure they are using cable whenever they can rather than a wireless connection. Regarding equipment, you should know that even the devices that capture and render the signal (such as headset or webcams) have great impact on the final quality because of their inner latency to process the audio stream. That is why it worth testing with certified Teams equipment to see if it provides a better end-user experience.
Enabling QoS (or Class of Service) on Your infrastructure
It means that backup traffic or conference traffic have the same priority even if the later is more critical in terms of speed. You can change that enabling the QoS on your infrastructure:
In the usual infrastructure, all packets are handled the same way by your network.
- On your managed external WANs
- On your managed internal LANs
- On your enterprise based Wi-Fi networks
For that you must:
- Deployed TCP/UDP Audio in the EF Queue (Expedite forwarding – DSCP 46)
- Deployed TCP.UDO video in the AF41 queue (Assured Forwarding – DSCP 34)
- Deployed TCP/UDP Application/Desktop Sharing in the AF21 queue (Assured Forwarding –DSCP 19)
Read more about implementing quality of Service (QoS) dor MS Teams.
It will assign higher priorities to network packets that are carrying audio or video data. This means they will travel faster and with less interruption than any other packets used for web browsing, database backup or file transfer. The QoS is already implemented inside the Microsoft Network, but keep in mind that this is never the case with your ISP. We will see how to work on that right after.
Investigating Network Performance Issues
Another way of optimizing your network without spending too much money upfront is to try to understand the root cause of potential test failures.
- A high “One-way latency” is often related to an incorrect routing setup. Therefore, you should investigate packet routing and implement an ideal route (see above).
- If the roundtrip time is higher than double the latency, it is certainly that one leg of the path is incorrectly routed. It can come from multiple causes such as a firewall issue or a bad router configuration. In any case, you should investigate your traffic path.
- A high packet loss is often a sign of bandwidth issues. The best thing to do is then check your available bandwidth and compare it with the Microsoft bandwidth calculator (see next section). It can also be linked with a wrong DSCP configuration.
- A high Jitter is usually a result of high packet loss. So you’re back to investigating the issue above.
- A high burst rate loss is a result of under provisioning or misconfigured queuing that you should then investigate.
- A low Network MOS is directly linked to either a high Jitter, packet loss or latency. You can calculate the MOS degradation factor that highlights which of these statistics are responsible for that situation and hence gives you an idea of what to investigate.
Finally, you must work on your bandwidth. You can calculate what you need thanks to the Microsoft bandwidth calculator available here >>
Calculating the bandwidth required, and the one you have available site per site should be your first task when you assess your readiness for MS Teams. The bandwidth will greatly affect all the other network metrics while using Teams services. If your site fails and you know that your bandwidth is currently limited, you should consider contacting your ISP and negotiate n increase. Sometimes it is possible at reasonable costs and sometimes it is not. But that is something that can greatly improve your end-user experience without involving large infrastructure project costs.
Interested in learning the best way to optimize your Microsoft Teams performance? Make sure to learn more about Martello’s Microsoft Teams monitoring solution and download our eBook ‘Ensuring Teams Performance when it’s OneDrive, SharePoint and Exchange Under the Hood’.