Multicast is a commonly misunderstood technology particularly with respect to OSD in ConfigMgr. The basic misperception revolves around multicast somehow being “magically” faster or better than the normal unicast method for transferring content to target systems. As with all technologies, there are times when multicast works well and times it does not.
What Is Multicast
Multicast is about sending a single stream of data from a source location to many endpoints simultaneously. Endpoints wanting to receive the stream of data specifically subscribe to this stream. It is then the network infrastructure’s responsibility to actually deliver the stream to these subscribing endpoints, duplicating it as necessary to reach them. Because the source is only responsible for this single stream, its workload is greatly reduced—this is great for large, continuous streams such as video that are destined for a nontrivial (possibly fluctuating) number of endpoints.
Conversely, using unicast to send that same large stream hundreds or thousands of times to deliver it to the same number of endpoints puts a huge burden on the source system as well as the network; this increases network latency and the source would suffer from resource bottlenecks as the number of endpoints increases. Sending a single stream from the source and duplicating it only as necessary addresses both of these issues.
How Does Multicast Help
If all the subscribers are on the same physical network segment, you have greatly reduced the overall network workload and bandwidth used because that single stream never actually has to be duplicated and yet is still delivered to all the subscribers. If those subscribers are spread out, the stream must be duplicated (by the network), roughly based on the number of different locations the subscribers are in. This results in less bandwidth savings; however, it is still far better than one stream for every client wanting to receive the data. Regardless, the source still sends out only that single stream.
Multicast is not meant to speed up deployments in any way: It is about saving bandwidth and reducing workload on the source. This in turn allows a single source system to deliver data simultaneously to a large number of systems without significantly affecting latency or other traffic on the network.
Two main factors slow down multicast:
The quality of the network gear (and configuration): The network gear is actually responsible for most of the work in multicasting and therefore critical. Cheap network gear or poor configuration of the network infrastructure will noticeably slow multicast performance.
Synchronization: Because you send out a single stream, the subscribers (aka clients) must be synchronized. If they miss a packet or a packet is corrupt or simply not delivered, too bad for you. With video, no big deal; you miss a frame. With data, it is a big deal. You have to wait until the stream is sent again; there is no reliable delivery mechanism because that would disrupt the stream for all the subscribers.
If a client joins a stream late, it has to wait until the stream starts over to catch up. Normally with multicast, all clients wait until a given time for the stream to start which adds extra time. Windows Deployment Services (WDS) has some advanced functionality that keeps track of which clients require “catching up,” but this still consists of clients waiting for the stream to start again. WDS also synchronizes the start of the stream based on a time delay or minimum number of clients.
A final implication of client synchronization with WDS is the speed of the stream is automatically adjusted down to accommodate the slowest endpoint subscribing to the stream of data. It makes no sense for WDS to send out the stream as fast as it could if some of the clients cannot keep up.
To Multicast or Not
This all adds up to a lot of overhead that increases the time for multicast in most typical OSD scenarios. Because of the bandwidth savings and smaller impact on the network, there is a point (in number of clients being serviced) where multicast is faster than unicast. What that point is depends on many factors such as the number of locations, proximity of the locations, number of hops, other traffic on the network, and quality of the network to name a few. Only testing can reveal what this point is for your network.
In general, for multicast to truly be effective and worth it, you have to be reimaging hundreds (or more) of systems in close proximity at the same time, or you must heavily value lower resource utilization over deployment time in a build lab. Otherwise, unicast is definitely the way to go.