There is quite rightly much focus on what can be done to help make streaming more sustainable. However, if we wait for a spectacular solution that solves everything and reduces emissions to almost nothing, we’ll most likely be waiting for a long time. Instead, we can adopt a mindset of every little bit helps, making changes where we can. For ease, let’s divide streaming into two parts: production, where content is created and pushed to the content delivery network (CDN); and distribution, where viewers pull the content from the CDN. Focusing on the content production side, because that’s where we have more control, there are changes we can make that not only bring about operational benefits but also have the potential of helping to reduce power consumption.
Somewhat surprisingly, there’s a technology that’s existed since the mid-1980s that may help content producers reduce the power they consume, and that is IP multicasting. So, how can something that’s almost 40 years old help content producers and broadcasters to reduce power consumption?
How IP multicasting works
IP multicasting is a way to send the same packets to a group of devices that have all opted-in to receive the packets. It’s receiver-driven which means the sender simply transmits the packets and does not care who is receiving them; whoever wants the content joins the group and starts receiving the packets. This is managed by the network, with receivers expressing their interest in the content via an Internet Group Management Protocol (IGMP). Although newer versions of this protocol allow for fine-tuning of what content the receiver wants, the key points remain unchanged: senders transmit only one copy of the content, content only goes where it is wanted, and content delivery can be optimised by the network.
You may well be asking what does this have to do with reducing power consumption? Well, it all boils down to only transmitting content to where it is wanted. This will save on bandwidth, and, to a lesser extent, also save power. If you can properly implement multicast, only one copy of the content ever comes out of the sender. Additionally, lower bandwidth requirements translate into lower-capacity equipment, and this also has potential power savings.
To see how IP multicasting works in practice, consider a sports event such as a football game or a Formula One race. There will be multiple cameras at the event, all covering different angles. If it’s a major event, all these cameras go to a production facility and a director will decide which ones go live. There isn’t much we can do to reduce power consumption for this main feed, but this is not the case if you have situations where there are several remote distributed editors, each producing a custom feed. They will need access to the cameras as well, but not all of them, and not all the time because each editor will dynamically choose which cameras to use. If you try to operate this type of workflow using one-to-one communication, bandwidth requirements scale very quickly, as does the size of the equipment required for transmission, and the power it takes. However, if you can pull only one stream from each camera, there are power savings to be had.
Missing links in the chain
It’s reasonable now to question if this is such a good idea, and has been around for almost 40 years, why isn’t it already deployed everywhere? The short answer is that up until fairly recently, the other parts of the solution needed to make it work have been missing.
The first part is achieving reliable content transmission over IP. The industry initially started using RTMP, which is based on TCP, and while this can sort of do the reliable transmission part (if the network conditions are favourable), TCP isn’t multicast-capable – so you’d need UDP for that. Then there is RTP, which runs on top of UDP and is multicast-capable, but natively doesn’t have the reliability aspect. There are other proprietary protocols over UDP, such as SRT for example, but these don’t support multicast either. Reliable Internet Stream Transport (RIST), on the other hand, is multicast-capable, can provide reliable delivery, and is an open specification.
The second part is the fact that the internet still doesn’t support multicast natively. The only way around that is to have unicast tunnels between multicast islands. These have existed since the late 1980s as well, but are now known as VPNs, and are combined with encryption and authentication. Many VPNs support multicast. There are now plenty of solutions to transport multicast over unicast transport, and this is making the technology more accessible.
Finally, there also needs to be some intelligence in the network to direct the multicast to where it needs to go. The general solution for this problem is the multicast routing protocols, including Protocol-Independent Multicast (PIM), Distance Vector Multicast Routing Protocol (DVMRP) and Multicast Open Shortest Path First (MOSPF). If the network is very simple, the recently approved RIST Multicast Discovery can also be used.
It seems that after many years, the different pieces needed to finish the multicast puzzle are finally coming together. We’ve got reliable content transmission over IP, solutions to transport multicast over unicast transport, and the necessary intelligence in the network.
While you clearly won’t save the planet by using multicast, it does seem that there are some distinct advantages to be had from using it, many of which align with sustainability strategies that seek to reduce consumption.
