IP Multicast: A Solution Looking for a Problem Since 1989?

Back in 1999 when I was working at UBC Media Group we liked the idea of using IP Multicast for distributing radio stations in the nascent streaming era. We did Shoutcast, we did Netshow, so why not multicast? So we tried to get it working. Over the internet. And of course it didn't work. It never has, and it probably never will. But why?

When Steve Deering published RFC 1112 in 1989, multicast looked like the future. Why send millions of identical packets when you could deliver one, let the network replicate it, and reach everyone at once? For live Radio, TV and mass events, it seemed obvious.

Thirty-five years on, multicast remains one of networking’s enduring curiosities: brilliant on paper, useful in niches, but never the mainstream delivery workhorse many expected.

The Promise

• Efficiency at scale: Perfect for when millions want the same content simultaneously.
• Broadcast heritage: A natural fit for live sport, concerts, elections.
• Eco-friendly logic: Fewer duplicated streams mean lower energy use.

What Went Wrong?

On whiteboards in the 1990s, multicast looked unstoppable. But deploying it across the open internet ran into a series of brick walls:

• Routing complexity: ISPs had to support multicast routing (PIM, IGMP, MSDP), which added operational overhead for little immediate payoff.
• Business incentives: CDNs and unicast scaling models gave ISPs and content owners billing clarity and customer control. Multicast offered efficiency, but not revenue.
• Interoperability issues: Internet-scale multicast required coordination between ISPs worldwide to implement the multicast equivalents of foundations like BGP and AS numbers (MBGP and MSDP). That cooperation never materialised.
• NAT and private addressing: The rise of RFC 1918 private addressing and ubiquitous NAT (Network Address Translation) in the 1990s created a hostile environment for multicast. Group membership signalling doesn’t traverse NAT gracefully, making multicast effectively trapped inside local domains.

...private addressing and ubiquitous NAT (Network Address Translation) in the 1990s created a hostile environment for multicast

• Security and rights management: Encrypting multicast streams and controlling access at scale is far harder than with unicast HTTPS sessions. Per-user DRM, subscriber entitlements, and audit trails are trivial with unicast but clumsy with multicast. ISPs also feared amplification attacks.
• ABR streaming + CDNs filled the gap: HTTP-based streaming (HLS, DASH) piggybacked on existing web infrastructure, solving the problem in a simpler, more flexible way - even if less bandwidth efficient.

In short, multicast didn’t miss because it was technically weak. It missed because the internet evolved around business models, user expectations and real-world challenges that favoured unicast.

Where are we now?

Viewing today is increasingly on-demand, catch-up, or watch-from-the-start. Even FAST channels, mimicking the linear experience, tend to offer watch-from-the-start and pause features. Audiences want control, not synchronisation. Those “everyone in sync” moments - the FA Cup final, the Superbowl - are notable exceptions, but they're outliers when we consider viewing as a whole.

Broadcasters, meanwhile, aren’t chasing bit distribution efficiency; they’re chasing addressable advertising, engagement data, secure conditional access, and personalisation. Delivering one identical multicast stream to millions means you lose security, targeting, analytics and revenue.

Delivering one identical multicast stream to millions means you lose security, targeting, analytics and revenue

And here's the thing about those "everyone in sync" events: They don't happen in a vacuum. Increasingly, the people watching would otherwise be consuming data bandwidth in a different way, whether that's watching VoD content, browsing TikTok or sitting on Zoom calls. Some might be watching in pubs or other social venues, consuming less data bandwidth than they normally would. If you're watching the Cup Final, you're not watching Netflix.

The CDN capacity required ends up relating more to the number of people being served than it does to the type of content they're consuming. Once a market has enough CDN capacity to handle the peaks of everyday traffic, synchronised viewing events are able to draw on that capacity when required, because less of it is then needed for other things. Live viewing peaks become redistributed load, not absolute load.

It's not the most efficient outcome from a bandwidth usage perspective, but the simplest one from an implementation perspective.

Live viewing peaks become redistributed load, not absolute load

Multicast does have Thriving Niches....

• Telco IPTV: Managed networks like BT TV use it effectively.
• Finance: Trading floors depend on multicast for synchronous low-latency market data.
• Internal broadcaster distribution: Inside major broadcasters, multicast is often used to deliver live feeds, studio outputs, and contribution streams across their internal IP networks. It’s an efficient way to provide hundreds of edit stations, newsroom desktops, and monitoring screens with the same live content without duplicating streams for each endpoint.
• Transitional deployments (eg Broadpeak/DAZN in Italy): DAZN’s rights to Serie A football ran into Italy’s reality: Telecom Italia’s broadband infrastructure couldn’t yet reliably deliver mass live streams over pure unicast. Broadpeak’s multicast ABR was adopted as a workaround - sending one stream into the ISP network, then adapting it for end-users.

....and Potential Niches

• 5G Broadcast Mobile networks do face brutal congestion during major events. 5G Broadcast offers a one-to-many model over spectrum, avoiding unicast overloads. IP multicast is used to deliver over an operator's network for 5G broadcast transmission, so If device support improves, it could push multicast into mainstream consumer use for the first time.
• Multicast ABR (mABR) Vendors like Broadpeak and Ateme propose hybrid models: deliver a single stream into an ISP network via multicast, then adapt locally for each device (bitrate, ads, personalisation). This could give operators efficiency without sacrificing user-level features.
• Enterprise & Edge Distribution From corporate video to IoT firmware updates, multicast could save bandwidth in repetitive, large-scale distribution - especially if cloud providers embrace it at the edge.

multicast has never found a way to navigate the disorderly structure of the open internet

But these all have one thing in common - an end to end network under singular control: multicast has never found a way to navigate the disorderly structure of the open internet, to deliver streaming content to end consumers, and it doesn't look like it ever will.

Perhaps Multicast is less “revolutionary broadcast” and more hovercraft of networking: technically ingenious, spectacular in demos, and occasionally useful - but ultimately stranded between promise and practicality?

🤔 But it's not the best analogy as hovercraft are notoriously energy intensive, whereas multicast would offer energy savings if it ever became possible to use it in the way we naively imagined back in 1999. I'll have to work on better analogies for my next article 😃.

➡️ Multicast’s story is a reminder that technology's purpose is not simply to be clever, but to solve real-world problems.

❓Do you think efficiency and carbon goals will finally make multicast a necessity, or will it remain the hovercraft of networking: spectacular, clever, but never quite mainstream?

#Streaming #Broadcast #Cloud #Networking #Standards

👉 Follow Paul Markham on LinkedIn for daily posts on Media Tech, Broadcast, Cloud and AI.