Broadcasting 101

Let’s talk broadcasting for a second.

If you look at how media is distributed to multiple users, then you will find out that there are several approaches to this challenge. At times, I am asked on this, especially with regards to how to achieve that with WebRTC; so I want to put some basic understanding out there on how I view things.

Disclaimer: I am not an expert in this domain (well… I don’t think I am an expert in other domains either, but it never stopped me from writing).

To that end, I want to go over 4 different general techniques of how to broadcast media to multiple participants over IP (none of them is “broadcasting” in its purest sense).

Multi-Unicast

The most naïve approach to broadcasting is to send multiple streams to multiple participants. Since a single stream is usually referred to as “unicast”, this approach is called “multi-unicast”.

Things to remember about this approach:

• It requires linear scaling of both processing power and bandwidth
• This means that the more users you have, the more servers and bandwidth you’ll need to allocate for the task
• You can send slightly different data to different users – for example, retransmission for packet losses
• Internet websites use this technique, though usually they do it via CDNs and not directly

Multicast

Multicasting is an approach that IP networks allow. There’s a whole bulk of IP addresses that are reserved for the task of multicasting. Essentially what this means is that if you want to “listen in” to specific content, you need to register for the relevant multicast address and miraculously, the media packets will get streamed your way as well.

Things to remember about this approach:

• It costs little on the processing power and bandwidth of the sending server
• It requires control over the network, as most switches and routers block multicast traffic, so you can’t really use it over the internet – unless you are the service provider
• It floods the network, as each registered address means that every router and switch along the path needs to receive that data
• There’s no rate control mechanism here that can easily be added simply because everyone receives the exact same packets of data
• IPTV service providers send their broadcast channels over multicast addresses

CDN

CDN is an approach taken to deal with the latency involved in sending media (and other resources) internationally.

If I have a server here in Israel, and the video that I need to share needs to be streamed to people in the US and Japan, then my packets are going to travel far. This will take time and aggravate my viewers. A better approach is to upload the content to a CDN, pay him a handsome fee, and have him deliver that resource for me, due to his global spread, this gives better service to my viewers most of the time.

Things to remember about this approach:

• It might not be suitable for all scenarios – real time can be challenging for CDNs
• Not all CDNs are born alike – they differ in their spread across the globe and inside service providers, price, SLA, type of content, etc.
• CDNs are actually beasts that use a multi-unicast approach

P2P

This one is BitTorrent – having the viewers of the content share it amongst themselves to assist in the delivery of the content and not rely only on a distributing server.

What is interesting here is that this is now also possible by using WebRTC’s data channel.

Things to remember about this approach:

• It depends on the capabilities and uplink characteristics of the peers that are collaborating
• The larger the “network” the more collaboration there will be between the links
• It can be used in parallel to using a CDN or other broadcasting approaches to reduce the load and cost of the solution

–

Your turn – feel free to correct me or add information to this one.