Why we use a multicast IP network for live content production
At Canal+, we do have a dedicated IP network for live content production. Live audio and video streams are transported by IP routers, and this IP network has multicast enabled.
By reading this article, you should understand the reasons why we have chosen multicast for this type of IP network.
But first, what are we talking about when we talk about multicast?
What is multicast?
Most network engineers are familiar with what IP multicasting is all about. For those who do not know this technology, a few principles are necessary for understanding.
Multicast is a point-to-multipoint mode of communication, which can be contrasted to unicast, which is point-to-point. A sender can address several receivers simultaneously in multicast, whereas in unicast, a sender must address each receiver individually. Multicast is particularly indicated when the receivers are interested in the same streams. An example of applications is an audioconférence, where the streams are audio streams.
In a multicast communication, we can distinguish the source, which emits packets to a special address that we name a multicast group, and the receivers that can join this multicast group to receive the corresponding packets. Of course, a receiver can play both the receiver and source roles simultaneously in the same group.
For a multicast communication to work, the IP network between the source and the receivers must have this feature enabled and configured. That is not always the case. For instance, it may work on a local network, but doesn’t on the Internet.
Multicast traffic is efficient
A special aspect of any multicast communication is that it follows a particular path in an IP network. This particular path having the shape of a tree, which is called a multicast distribution tree:
- The source send packets at the root of the tree.
- In the IP network, at each tree branch, the IP packets are replicated by the IP routers from the source branch to the destination branches, and only towards these.
- Receivers get the IP packets at the leaves of the tree.
Packet replication occurs only when the paths diverge in the tree. On the common path, upstream to the source, there is only one copy of each multicast IP packet, and not one copy per receiver, as that would be with unicast. This saves bandwidth, because in unicast the same stream would have been duplicated for each receiver.
The more you have receivers, the more you save bandwidth. For instance, in the case of IPTV broadcasting, there may be millions of subscribers behind a multicast interconnection with an operator. This can really save a lot of money.
At Canal+ we massively use multicast in our IP network dedicated to live content production. Even though it often happens that a video source is subscribed by many receivers, on average the number of sources and receivers is in the same order of magnitude. Ten receivers for a single source is huge. Most of the time, a source only has a single receiver, and sometimes even none! So why multicast?
With only a few receivers of compressed video streams per source, it’s true that overall bandwidth savings are quite low. However, with uncompressed video, bandwidth savings start to be interesting in absolute value (relative savings is the same between compressed and uncompressed video). For instance, an uncompressed Ultra-HD video stream consumes up to 10 Gbps of traffic. Each avoided copy saves 10 Gbps of bandwidth. For this type of stream, the economy is significant.
In our IP network, savings are especially important considering the source dimensioning. To illustrate, let’s consider a 10 Gbps port of an IP router on which a source is connected. This source can only send one uncompressed Ultra-UD stream. Using unicast, we would be stuck with a single receiver. Using multicast, an unlimited number of receivers can join the group and receive the video stream. This example can be transposed to any combination of streams and port sizes.
What you should remember is that the dimensioning of a multicast source is independent of the number of receivers, whereas it is proportional to the number of receivers in unicast.
In brief, while moderate, bandwidth savings achieved thanks to IP multicast remains interesting in our IP network, even with few receivers per source. Above all, it solves the problems of saturation that could occur at the source as the number of receivers increases.
Multicast helps scaling the overall system and make it more resilient
So far, we didn’t explain how a receiver could join a multicast group. When a receiver wants to join a group, it simply asks the IP network. How?
Without going into details, a receiver uses a protocol called IGMP. It exchanges some IGMP messages with the IP network, in which it indicates the multicast groups he is interested in, and optionally the source.
The IP network aggregates all these messages and uses another protocol called PIM to build the multicast distribution tree mentioned above within the IP network.
The IP network then works as an intermediary between the sources that transmit streams of data without knowing who will get them and the receivers that can join or leave multicast groups dynamically. The IP network also acts as a distributed and resilient register keeping track of all the sources and all the receivers for all multicast groups.
Whenever the source is unknown when a receiver joins a multicast group, the IP network finds it, if any is transmitting or starts to transmit in the relevant group, so that the receivers do not miss it. The source and the receiver just have to belong to the same multicast group. Conversely, when a source is moved from one place to another, there is no need to inform the receivers.
Whenever an IP router fails, only that router’s (local) data is lost, but all other data remains available on other IP routers. This makes a fairly resilient distributed system.
There is no equivalent to this distributed register in unicast. Modern architectures are based on different network services like DNS or load balancing, with data synchronization and replication mechanisms.
To sum up, our multicast IP network acts as a simple distributed register and avoids introducing other additional technologies to ensure the scalability and resiliency of the system. It is an elegant solution to limit the overall complexity of the system.
Ensuring quality of service is easier in a multicast IP network
Most IP routers offer features to ensure quality of service by prioritizing certain types of traffic over others. For instance, it is quite easy to give priority to DNS over HTTP traffic, by creating 2 different classes of service. However, within a class of service, the IP router discards packets that overflow the class queue, and packets drop seems random. In the previous example, the IP router would discard some HTTP packets during congestion to preserve DNS packets.
In a multicast IP network like ours, however, this classic model has some limits. On the one hand, it’s not that simple to define priority rules between media streams. On the other hand, even if we could define these rules, the behavior in the event of saturation within a class of service is not what we are looking for, because packet discards within that class seem random. That means that when a new multicast stream causes a class of service to reach saturation, this additional stream will create packet drop in all other established multicast streams of the same class. Packet drop will create artefacts on the image of the video streams or on the sound of the audio streams, or might even bring them down.
The right solution would be to only accept streams for which the IP network has enough capacity, akin to what happens in a circuit-switched network like the traditional public telephony network, and to block multicast streams when the IP network does not have enough resources.
The IP network we use at Canal+ is built upon Cisco Nexus 9000 hardware. These IP routers have a multicast traffic protection feature called NBM which precisely makes it possible to prevent such problems. NBM is not a protocol but a feature set that enriches standard multicast protocols, without affecting neither messages nor interoperability with non-NBM IP routers. All NBM decisions stay local to the IP router.
Here are the main NBM capabilities:
- NBM reserves the bandwidth needed by each stream on each link, calculates the bandwidth remaining and compares it to the bandwidth needed by a new stream before being established. In case of overflow, the establishment of the multicast distribution tree is put on hold until other streams are released and enough capacity can be reserved for this new stream. This admission control mechanism thus makes it possible to preserve the streams already established.
- NBM makes it possible to bring down lower priority streams to recover their bandwidth and reallocate it to higher priority streams when saturation occurs.
- NBM ensures that a stream does not exceed the reserved capacity by setting up a traffic policer at the source of the stream. This makes non-compliant streams probably unusable, but at least preserves all other established and compliant streams.
- NBM ensures an optimal load sharing when several paths in the IP network are available, and allows intelligent routing when one of the links on a path no longer has sufficient capacity.
We will have the opportunity to talk about NBM again in another post.
In short, bandwidth protection features are particularly powerful in a multicast IP network like ours.
Conclusion
IP multicast technology enables efficient network usage by allowing a data stream from one source to be replicated as late as possible and only when necessary. Moreover, although rudimentary, a multicast IP network also acts as a distributed register and maintains the association between sources and receivers, enabling scalability and resilience of the overall system. Finally, the multicast traffic protection features are particularly important to us.
There remains an important element I did not mention, which is the state of the market. The industry has overwhelmingly adopted multicast for a long time, and it is so natural in the live video content production ecosystem. However, nothing guarantees that traffic will remain multicast indefinitely. Moving to the public cloud could be a game changer, even if it is still too early to conclude.
