Delivery Optimization and 'Non Peerable Content'

Good day fellow content peering nerds!. This is a bit of a recap of part of our our recent session at MMSMOA, where we tried to explain the complexities of content delivery statistics and the recent 'somewhat puzzling' downwards trend in the efficiency of Windows Delivery Optimization (DO).

It was triggered by seeing the 'DO Efficiency' numbers on a slippery slope at a few of our customers. We monitor this kind of thing in our StifleR product in some detail and it was troubling to say the least! For those of you who don't know - one of the key functions of 2Pint StifleR is to provde templates for Delivery Optimization settings in all kinds of different scenarios (VPN, fast networks, slow networks, home workers) etc, and our first thought was 'what are we doing wrong'!? Has something changed in the DO client or backend services? After some analysis however, it turned out to be reasonably straightforward.

We always knew that certain DO content wasn't 'peerable'. Microsoft publishes and updates this list here: Delivery Optimization - Windows Client

Here's the important table, with the 'non-peerable' content highlighted. If you compare the 2023 version of the table with the 2024 list, you can see that the amount of 'non-peerable' content is growing, not shrinking!  We don't like this trend...

DO Content - 2023 Edition

DO Content - 2024 Edition

Impact of Non-Peerable Content

Back to our 2Pint customers. In one case, there was a 20% drop in peering efficiency, so we decide to do some analysis over three days of DO content downloads back in Feb 24. It was interesting! As you can see below, there was a sudden surge in MS Teams content downloads (28.8 Terrabytes over 3 days), which was our 'eureka' moment, as it explained the sudden downturn in DO peering as MS Teams updates cannot be peered or cached by MCC. Ouch, New Teams Client FTW!

The other day I even caught one of these downloads on my own laptop, and using the 'Get-DeliveryoptimizationStatus' PowerShell cmdlet to capture the download in mid flow, you can see the culprit below. It's 137MB, which is not huge by any means, but if every single one of these updates is non-peerable, and they are pretty damn frequent, (they are), then things quickly add up if you are servicing many endpoints.

You can see that the caller app is MSIX, which is what Teams uses as the installer for its updates. In the example below I also managed to grab the URL, which is the other reason that the content can't be peered. DO (currently) can only peer or cache content from http sources, so there's nothing that can be done..

The impact therefore is that the overall DO Efficiency or 'Bandwidth saved' by using P2P can be greatly reduced.

Help, All Is Lost, My Network Is Doomed!?

So what can be done about this non-peerable content? Well I'm not gonna lie folks, not much. 

Maybe we could somehow control the Teams updates at least? At first glance after a bit of googling, it seems not. Automatic Updates for Teams is part of the Servicing Agreement, as referenced in this MS page:  https://learn.microsoft.com/en-us/microsoftteams/new-teams-bulk-install-client

At least now you know what is and isn't peerable, and you can factor that into your DO reporting.

Overall, the best thing that you can do is to make sure the the DO content that IS peerable is dealt with as efficiently as possible. That's what we do within our StifleR Product, so if hands free DO management floats your boat, give us a shout :-) 

If you want to know the latest 2Pint recommendations for Excellent DO Peering, well that's coming soon, too!