Multicast Comes to the Open Internet

For decades, the streaming industry has carried around a simple, almost stubborn dream: send one stream, reach everyone. It’s the cleanest idea in networking—one upstream feed that branches only where it needs to, instead of millions of identical unicast sessions hammering the same networks at the same time. That dream has a name: multicast. But while it was great for managed networks (where the operator had complete control over the origin and the endpoint), it didn’t fare so well on the open internet. And, let’s be honest, even in closed networks, there was reticence to deploy it because of the cost of swapping out gear and updating consumer equipment.

The long and short of it? Just as streaming consumption grew exponentially, squeezing the limited available capacity, the industry couldn’t take advantage of one of the key technologies that would have solved that problem.

Today, that’s changing. Not because the internet suddenly became a managed network, but because the missing pieces finally exist to make multicast work across the messy, heterogeneous, real-world internet we actually have.

Before diving in, here’s the quick summary.

TL;DR

• Multicast has always been the right answer for workloads where many users need the same data at the same moment. The problem was deployment: the open internet couldn’t coordinate native multicast across thousands of networks.
• Two IETF specifications—AMT (RFC 7450) and TreeDN (RFC 9706)—let multicast cross unicast-only networks, combine native multicast and tunnels into one delivery tree, and push shared delivery deeper into the edge.
• Combined with programmable edge nodes like the Blockcast RELAY, multicast‑over‑the‑internet becomes a practical, capacity-saving tool for any workload where many people want the same data at once.
• The future of delivery is heterogeneous: unicast, multicast, Media over QUIC (MoQ), caching, pre-positioning, and edge replication working together. The winners will be the providers who unlock capacity wherever it exists.

The Old Dream: One Stream, Many Viewers

Streaming grew up in a unicast world. One viewer requests a stream; the network sends one stream. A million viewers request the same stream; the network sends a million streams. CDNs helped by caching content closer to users, but they didn’t change the underlying math: every session still consumes capacity. That works until everyone wants the same thing at the same moment, and the real trouble starts when big events overlap: millions of viewers on one, millions more on another, all filling the same network capacity.

Live sports, global premieres, breaking news, esports finals, emergency alerts, OS updates, game patches, AI model releases all of which don’t politely distribute demand across the day. They concentrate it. They hit the same regions, the same access networks, the same peak windows.

That’s where the old multicast dream stops being nostalgia and starts being a capacity strategy.

Of course, you might say, “Netflix handles huge audiences without multicast.” It does, by placing its own servers inside ISP networks around the world (Open Connect), and even that strains under live demand: Netflix’s November 2024 stream of the Paul–Tyson fight drew widespread buffering complaints. Few content providers can afford to keep throwing physical infrastructure at the capacity problem. The rest rely on CDN operators, who add capacity based on their own priorities, not the content provider’s. And new capacity can’t be turned up at a moment’s notice.

Why Multicast Never Became the Internet’s Default

To understand why multicast didn’t become the internet’s default delivery mode, you have to understand how multicast actually works.

How Traditional IP Multicast Works

At its core, multicast is simple:

• A sender transmits packets to a multicast group address.
• Receivers join that group using IGMP (for IPv4) or MLD (for IPv6).
• Routers maintain forwarding state for each group.
• Packets replicate only where paths diverge.

Instead of sending N identical streams to N viewers, the network builds a distribution tree. One stream becomes many streams only where it must. That’s what makes it so efficient for anything many people want at the same moment.

But multicast assumes something the internet doesn’t provide: cooperation. Routers must support multicast forwarding. Operators must enable it. Domains must coordinate. Traffic must be managed, monitored, secured, and billed. Receiver behavior must be understood. Operational teams need tools and confidence. That’s why, inside a managed network (campus, enterprise, telco, broadcaster, datacenter), multicast works and exactly why, across the open internet, it doesn’t. The internet is not one network. It’s thousands. Each with its own policies, equipment, incentives, and routing choices. There is no guarantee that the source network, transit network, access network, and home network all support the same multicast behavior.

That’s why multicast never became the default way content reached end users.

Unicast vs. Multicast at Scale

Unicast scales linearly with audience size. Multicast scales with branching points, not viewers. For example, if 50,000 people in a region watch the same stream:

• Unicast treats them as 50,000 delivery obligations.
• Multicast treats them as one upstream stream that replicates only where paths diverge.

It’s important to understand that multicast doesn’t replace unicast. It handles the part of demand where unicast is structurally wasteful.

AMT and TreeDN Change the Deployment Model

Two IETF specifications make multicast over the internet practical: AMT and TreeDN.

AMT: Automatic Multicast Tunneling (RFC 7450)

AMT solves the biggest historical barrier: how do you deliver multicast to receivers on networks that don’t support multicast? AMT does this by creating lightweight unicast tunnels between:

• AMT relays (in multicast‑enabled networks)
• AMT gateways (in unicast‑only networks)

Here’s how it works:

1. A receiver joins a multicast group through an AMT gateway.
2. The gateway discovers a relay (by anycast, or by DNS per RFC 8777) and sends it a unicast request.
3. The relay encapsulates multicast packets in UDP.
4. The gateway decapsulates them and delivers them locally.
5. The receiver sees multicast, even though the network isn’t multicast‑enabled.

This matters because:

• No consumer devices need to be replaced.
• No access network needs to be rebuilt.
• Operators can deploy relays where they make sense.
• Multicast can cross unicast‑only parts of the internet.

AMT makes multicast incrementally deployable, not globally dependent.

TreeDN: Tree‑Based CDN Architecture (RFC 9706)

TreeDN (RFC 9706, 2025), co-authored by Juniper’s Lenny Giuliano, Verizon’s Chris Lenart, and GÉANT’s Rich Adam, isn’t a new protocol. It’s an architecture that combines two that already work: Source-Specific Multicast (SSM) inside networks that support it, and AMT to reach receivers on networks that don’t. Routers and AMT relays replicate packets only where paths diverge. Every network that turns on native multicast shortens the tunnels and saves more. Operators run it with the PIM-SSM and AMT tools they already have.

AMT Has a History. Bringing It to the Browser Is the Breakthrough.

AMT did not arrive yesterday. Its development stretches back to the early 2000s, with IETF work on automatic multicast tunneling already underway in 2005. The goal was familiar: let receivers reach multicast content even when the networks between them and the source did not support multicast. After years of development, the IETF published AMT as RFC 7450 in February 2015.

So the protocol has been here for more than a decade. The opportunity has been here even longer.

But a network standard and an everyday streaming experience are two different things. AMT provided a way across the connectivity gap. Getting that traffic into the browser, where so much internet video is actually watched, still required another bridge.

A web page cannot simply open a raw UDP socket, join a multicast group, and start receiving AMT packets. Browsers expose a different set of networking capabilities. That left a practical gap between what the network could deliver and what a browser-based player could consume.

This is where Blockcast has focused its innovation: bringing AMT to the browser.

Blockcast connects AMT delivery to browser playback through its software transport bridge. The bridge handles the network capabilities the browser does not expose directly, while the page keeps playback, decoding, rendering, and controls. Viewers can watch in the browser instead of moving into a separate player application. That browser-to-network connection is visible in the Blockcast live demo webpage where you can also take a look at latency, loss, and relay fan-out.

There is a useful distinction here. Bringing AMT to the browser does not mean browsers suddenly support native AMT themselves. Blockcast supplies the connection. Depending on the deployment, that can involve a local software bridge or browser extension. It brings the capability to existing hardware without requiring consumers to replace their devices.

For content providers, that closes an important deployment gap. Multicast can carry shared demand efficiently through the network, AMT can bridge networks without native multicast connectivity, and Blockcast can connect that delivery path to the place the audience already watches.

The capacity benefit still depends on where shared delivery reaches: individual unicast tunnels consume individual bandwidth. But bringing AMT into the browser experience makes those efficient upstream paths usable by more applications and audiences. That is what turns AMT from a networking capability into a practical part of internet streaming.

Multicast at the Edge Changes the Capacity Math

Capacity, not demand, is the real constraint in modern delivery.

Demand is abundant. Content is abundant. User appetite keeps growing. The bottleneck is getting bits to the right places at the right moments without blowing up the economics. The issue in today’s streaming world is that unicast capacity is expensive: transit, peering, CDN commits, regional buildout, servers, storage, power, ports, and the people to run it all.

And peak events make the problem worse. While a championship match lasts a few hours, the capacity planning lasts all year. Thankfully, multicast reduces the duplicate traffic across constrained paths. It lets shared content behave like shared content. And when multicast reaches the edge (through nodes in access networks, campuses, venues, municipal networks, small data centers), the efficiency compounds. The edge stops being the place where unicast fans out one-by-one. It becomes an active replication layer.

Beyond Video: Files, Games, Updates, AI Assets

Most of the talk about capacity has focused on streaming video, but the problem multicast solves goes well beyond video. Game downloads, OS updates, security patches, AI model weights, training assets; basically, any workload where large numbers of users need the same data suffers from the same inefficiency. The network sends repeated copies of the same object to users in the same region.

Multicast‑over‑the‑internet lets edge nodes:

• Receive shared objects
• Cache them
• Translate them
• Serve them
• Present familiar delivery modes downstream

It fits into existing workflows instead of demanding a global reset.

What about packet loss? Multicast runs over UDP, so there’s no TCP retransmission to lean on. Blockcast protects its multicast streams with forward error correction (FEC), which lets receivers rebuild lost packets without asking for them. When loss exceeds what FEC can cover, a receiver fetches just the missing byte ranges over unicast and checks the finished object against the sender’s digest, so a file arrives byte-for-byte intact. Live video gets the same safety net within its playback deadline: a player that can’t rebuild a block fetches extra repair symbols for just that block, keyframes first.

The Blockcast RELAY Node

This is where the Blockcast RELAY node comes in. The name overlaps with AMT, so to be clear: an AMT relay is a protocol role defined in RFC 7450, while a Blockcast RELAY is Blockcast’s edge node: an edge cache that also runs an AMT relay. A RELAY node can:

• Participate in multicast delivery
• Serve unicast traffic
• Support MoQ
• Collapse duplicate traffic
• Extend CDN strategies
• Improve regional resilience
• Make underused infrastructure useful

A RELAY is programmable capacity at the edge, and because it’s software, an operator can run it on infrastructure they already have and aren’t fully using. CDNs remain essential to delivering content over the internet. Unicast remains essential. Managed networks remain essential. But the next phase of delivery needs more than bigger versions of the same architecture. That’s where the capacity issue has really hit home: building out physical capacity is expensive. But all of those networks that are already operating, just not part of traditional content delivery flows, have spare capacity. Multicast to the edge, through a node like a Blockcast RELAY, addresses the content delivery capacity challenges. It lets content providers deliver more cost-effectively through multicast while keeping their existing delivery infrastructure and partners.

A Heterogeneous Future

Multicast‑over‑the‑internet finally brings multicast economics into internet delivery without waiting for the whole world to change first.

Some traffic will be unicast, some multicast, some MoQ. Some will be cached, pre-positioned, or replicated through trees, and some will be served from deep edge nodes that didn’t exist in yesterday’s CDN map.

The winners won’t be the providers who force every workload into one architecture. They’ll be the providers who unlock capacity wherever it exists.

See it for yourself: the Blockcast live demo at www.blockcast.network/live plays the same ISS feed over QUIC, AMT, and native multicast side by side, with live latency and loss numbers for each (the AMT and multicast panes use Blockcast’s browser extension). If you run a network and want to host a RELAY, or you deliver content that many people watch at once, get in touch.

FAQ

What’s the difference between native multicast and AMT?

Native multicast requires routers to maintain multicast forwarding state. AMT uses unicast tunnels to deliver multicast traffic across networks that don’t support native multicast.

Does multicast replace CDNs?

No. CDNs remain essential for caching, distribution, and global reach. Multicast reduces duplicate traffic in high‑simultaneity scenarios.

Does multicast replace unicast?

No. Unicast is still required for personalization, interactivity, long‑tail content, and device compatibility.

What workloads benefit most from multicast?

Live video, game downloads, OS updates, AI model distribution, emergency alerts, and any workload where many users need the same data at the same moment.

Do consumer devices need to change?

No hardware changes. A browser extension or local bridge is needed only when multicast is carried all the way to the viewer’s device.

Is multicast secure?

SSM means receivers accept traffic only from the source they asked for. AMT uses a nonce and a message authentication code, so attackers can’t spoof joins or use relays to reflect traffic. Blockcast can also authenticate the multicast packets themselves (TESLA on ROUTE streams, ALTA signatures on browser streams), so receivers can detect injected or tampered packets. Content protection, such as encryption and DRM, works the same as it does over unicast.

What is the impact on existing video players and software download managers?

None when a Blockcast RELAY at the edge converts multicast back into standard HTTP responses: players and download managers see an ordinary CDN edge server and work as is.

Why now?

AMT has existed since 2015, so the protocol isn’t what changed. What changed: TreeDN (RFC 9706, 2025) defined how to build delivery trees from native SSM and AMT; AMT relays now run in the Linux kernel and on routers already deployed at ISP and IX edges; and Blockcast brings AMT into the browser, so viewers can watch without a separate player app.