Share via

Troubleshooting low peering efficiency

  • Article

In this article, we list common causes for low peering efficiency and how to address each.

Small live event

Generally the more popular the event, the stronger the offload performance. Keep in mind that at least one viewer in a peering group needs to download the data from the original source. So, if there are only two viewers in a group, the maximum peering efficiency/offload is 50%, 3 viewers=> 67%, 4 => 75%, and so on.

Excluding edge cases, the Microsoft eCDN SDK creates up to 30 peering connections. Only viewers that are watching the same resolution content peer with each other. By increasing the number of viewers in a group, the pools of available peers are expanded, which effectively improves the peering efficiency potential.

Suboptimal client access

For the most optimized Teams live event and town hall experience, all viewers should join via the Teams Desktop application. With the Teams client, Microsoft eCDN automatically obtains end-users’ local IPs and effectively peers them with one another.

If viewers join via the browser, ensure they grant microphone or camera access to the Teams website, or have mDNS IP masking disabled. By doing so, the local IP address that is required for peering is exposed. For more, see the disable mDNS IP masking documentation.

Lack of subnet mapping

With Microsoft eCDN, admins can incorporate their own subnet mapping in order to build peering groups/restrictions based on local IP. The benefits are:

  • Only viewers that are on the same network peer with each other

  • Cross-site peering can be prevented

  • Enriched analytics show site-based peering and performance

  • VPN subnets (and other subnets for which admins want peering disabled) can be explicitly excluded

Subnets can be uploaded directly to Microsoft eCDN portal's Subnet Mapping page. The required subnet mapping format is a CSV file with the following structure.

CSV table with three columns titled 'site name', 'network / C. I. D. R.s', and 'config' populated with sample data.

Refer to the subnet mapping documentation for guidance and more options on how to prepare your CSV for upload.

Without subnet mapping, all clients (that successfully expose their local IP to the eCDN SDK) are free to peer with each other. This scenario is great for maximizing potential peer count, but may allow for undesired peering connections to be formed such as through VPN channels, or across distant sites, leading to poorer performance.

Hyper subdivided subnet grouping

Similar in nature to the aforementioned small live event case. If subnets are over-aggressively subdivided, the corresponding offload potential is proportionately reduced.

High latency between two clients

Perform a latency test. For the optimal experience, latency between two clients should be less than 30 ms. To protect the user experience, clients won't utilize poor peering connections with high latency. One potential cause for high latency could be due to too many people being connected to a single network device, such as an access point or Switch.

Usage of a VPN (only relevant to testing)

This scenario is only relevant to the person administering a test from home and using other personal devices. Make sure VPN is disabled on test devices.

If you're in the office, it isn't recommended to access the video content via a VPN.

Incorrect local IP identification

Press Alt+Shift+P in a Microsoft eCDN-supported video window to open the stats overlay. A different IP address than the expected local IP address can be observed. In this scenario, the viewer is assigned to the wrong subnet group, potentially the Ungrouped (no peering) group. Consult your Microsoft Customer Success Account Manager (CSAM) for a solution.