WaaS - Download Size Don't Matter

Following on from the last post that provided some background knowledge for WaaS, in this post we’re going to cover off one of the issues that always gets the IT folks jumping when you tell them we’ll be pushing 100’s of GB worth of data about the estate every day - update sizes.

In truth, its not just the Feature or Cumulative updates we need to worry about, its also driver updates, MS apps and enterprise apps. So first we’ll cover off how WaaS updates are optimised to keep the size down and how that in turn keeps all devices in the estate at the same patch level. We’ll then go on to discuss the various technologies used when pushing these large volumes about the estate. Lastly we’ll talk about how your network utilisation is going to go up dramatically, but how it’s also a very good thing (honest, true story!).

Important note: We’re going to be discussing forward and reverse differential compression which is used to both patch and upgrade Windows 10 however, this is not the technology used to patch and update Windows 11. Windows 11 uses reverse update data generation and while it’s based on the same principle it works in a slightly different way making it 40% more efficient. The obvious question is why doesn’t Microsoft use this technology on Windows 10 and the simple answer is because they want you to go to windows 11. To be clear, the Windows 10 technology is really good it’s just that the Windows 11 technology is even better. Therefore keep in mind this section specifically applies to Windows 10 however windows 11 works in a similar way.

How W10 is updated

To say this is complicated is a little bit of an understatement however, I’ll try to make it simpler than Microsoft do. Firstly let’s start with some of the language:

RTM - release to market. In this context, this is the first release of a base Windows 10 version, before any monthly patches are applied (told you it’s complicated). As you know each year the Windows 10 version changes with the most recent version (at time of writing) being 21H2. The RTM version of 21H2 was the one released in November of 2021.

Delta package - also known as a Quality update patch.

So the principle is that we add the RTM version (lets call this version 0 or V0) to the first delta package (we’ll call this delta 0 or D0) and what we get is Version 1 (V1). Lets put that into an equation:

Version 0 + Delta 0 = Version 1

V0+ ∆0=V_1

(∆ is the fourth letter of the Greek alphabet = Delta).

So with that math lesson out of the way :wink: when we add version 0 to patch 0 we get version 1. Our equation also works when we get further along the WaaS release cycle:

21H1 + June patch = V0+ ∆2=V_2

In other words we take the first version, add the delta, and that gives us the new version. So why is this important? It’s important because to apply the next delta we take the old one away. Let’s go back to our equation and work that through. If we say 21H1 + June patch (V0+ ∆2=V_2) takes us to 21H1 v2, when we remove ∆2 we’re back to V0 i.e. we’re back to the RTM version of 21H1 - makes sense right? So it follows that when we then apply ∆3 we get V0+ ∆3=V_3 (Simple!! mmmm)

Lets now think about what a monthly patch contains: any code changes to any files, from the RTM version. If in the RTM version we had a file that contained these lines:

1. I have a cat
2. His name is Bob
3. He loves to eat

Then we realise that we made a mistake on line two and so the delta patch contains the substitute line:

2. His name is Dave

Note that the patch only contains the code changes to line two, it does not contain a replacement copy of the whole file. So the process is; download the delta patch, save a copy of the original file and replace line 2 and now our file looks like this:

1. I have a cat
2. His name is Dave
3. He loves to eat

We now have a copy of the original file and one with the updated version in production so we have the capability to go back to RTM if we need to. This is known as Reverse Differential Compression and is used for Windows 10 patches within a version boundary. Upgrades use the same technique however the saving of the original files works slightly differently in that they are automatically deleted after a set period of time.

As previously mentioned, Windows 11 uses a slightly different, more efficient technique in that rather than keeping a copy of the changed file, it keeps a record of the lines that were changed in a sort of index. When patches are applied the the changes are again written to the index with and previous changes updated. This means that less data is downloaded and stored by the endpoint, and update times are much shorter.

Bandwidth Management

Now that we’ve covered how the update process works, let’s talk a little about how we get all those updates and upgrades around an Enterprise estate. To achieve this we use three technologies, two that are in active development and one that’s not. I’m going to assume your estate is spread over multiple floors, across different buildings, different countries or even continents. Even if this is not the case, these technologies still apply to you so don’t skip this bit thinking it’s not relevant.

BranchCache is a Peer-to-Peer technology that was introduced in Windows 7 and Windows Server 2008 and allows a device to share content with its peers on the same network subnet. The configuration to enable BranchCache is performed using policy settings and is applied to every endpoint device in the estate. Once enabled, there is no further configuration required.

BranchCache is designed to limit impact to the WAN and works seamlessly with SCCM, Intune and Connected Cache. It should be noted that basic bandwidth optimisation algorithms are used by BranchCache to limit the impact to the local device i.e, if the client link is busy servicing applications, BranchCache waits until the client is less busy before downloading or uploading data from/to other devices within the same subnet.

The content request process is as follows:

• Client request content location from the management point
• Management point responds with content locations available
• Client broadcasts on it sudden it for any peers with the required content
• If no response, the client queries the distribution point
• If no response, client queries to fallback distribution point (if available)
• If no response, the client returns to the management point and the cycle repeats

The above is written from an SCCM perspective but the same principle applies when using Intune. Note: Branch cache is enabled by default in distributed cache mode when the Intune client is installed and is used to provide the peer-to-peer capability for packages and Windows updates/upgrades. You can read more about BranchCache here.

LEDBAT - Low Extra Delay Background Transfer is a latency optimized, network congestion control provider (sounds impressive doesn’t it :wink:). What this basically means is that it consumes all available bandwidth to download content, until that bandwidth is required by another service, and then it releases control. As a scavenger protocol, it’s designed to automatically yield bandwidth to users and applications, while consuming any available bandwidth for background transfers when the network is not busy:

• When increased latency is detected (indicating when other TCP connections are consuming bandwidth) it reduces its own consumption to prevent interference.
• When latency decreases LEDBAT ramps up, consuming the unused bandwidth.

As this technology assists with avoiding LAN saturation by background transfers, by extension it will avoid risks to critical applications from update distribution and application downloads. In short, Microsoft Updates can be transferred without interfering with critical application traffic on the device.

Note: As mentioned, LEDBAT will consume any available bandwidth when it is not in use and this gives the impression that the connection is swamped however, this is not the case. As highlighted the usage will back down if foreground traffic is detected. Also note that LEDBAT is self-configuring i.e. there’s nothing for you to change/configure. You can read more about LedBat in this blog post.

Cubic is a technology designed to be used in attended scenarios i.e. where there is a user device. It tries to optimize network throughput by sending packets faster and faster until one of them is dropped, and it then slows down and repeats the behaviour.

Because the sender keeps increasing the sending rate, eventually the network queue will be full resulting in dropped packets. When a packet is dropped (besides retransmitting) Cubic slows the sending rate by half (draining the queue) and repeats the process. The queue repeatedly fills and drains from this process, optimizing throughput. Cubic is part of the Windows 10 core and does not require installing/enabling.

Conclusion

We’ve covered how updates, upgrades and indeed packaged applications can be reduced in size using delta published changes. These keep the content to the minimum size reducing pressure on the Internet and WAN connections. We also discussed the use of different tools to push large amounts of content around the network with limited impact. In the next post we’ll discuss a cloud technology known as Delivery Optimisation which uses all the above tools to point a client to the best place to get the content it needs, while at the same time reducing the internet usage.

Happy reading and as always, feel free to reach out if you need a little help.