Let's suppose that Globomantics acquired a new concert ticketing company
to expand its business portfolio and rebranded it as GloboTicket. To
celebrate the acquisition, Globomantics is planning to roll out a
multicast deployment so that employees can tune into concerts and watch
their favorite performers live.
This new perk is likely to be very popular,
but Globomantics wants to ensure that this new traffic won't
overwhelm the network. Without multicast,
each user would consume a certain amount of network bandwidth and resources.
If a popular performer takes the stage,
this new perk could quickly become service‑impacting. For every
user that wants to tune in, a separate stream would need to be set
up, duplicating all the data. Multicast is the logical middle
ground between unicast, a one‑to‑one traffic flow, and broadcast, a
one‑to‑all traffic flow.
With multicast, we can adopt a more optimized traffic profile,
whether it be one‑to‑many or many‑to‑many.
One‑to‑many flows allow a single source to send one stream of
traffic into the network, limiting the resource, session, and
bandwidth requirements for that sender.
This optimization continues as the traffic moves throughout the network,
allowing traffic duplication to be avoided,
potentially all the way to the receiver.
In addition, that traffic will only be delivered to
those who are looking to receive it,
saving processing cycles on uninterested hosts.
This differs from a broadcast‑type solution that would hit every
host on the same LAN and require each of them to spend time
processing and ultimately discarding the traffic.
Many‑to‑many flows aren't quite so clean, but are still
more optimal than broadcast‑type traffic because only
interested receivers will get it.
Many‑to‑many flows are often seen in cases where there's a need,
not only to receive a flow, but send one as well.
IP‑based paging systems in warehouses and some
IoT‑based applications fit this model.
It's also common in financial systems where stock trading information
can be shared in this manner between the traders.
In any case,
the main differentiator of many‑to‑many flows is that there are
multiple multicast flows to track, each one tracked from that
source to its particular receivers.
This seems more complex,
but it's really just a duplication of one‑to‑many flows from different
sources to other receivers. Because the tracking of so many multicast flow
states can be a resource‑intensive task for the routers, there is a
multicast solution to tackle this exact use case,
which we'll discuss later.
Regardless of whether the traffic flows are one‑to‑many or many‑to‑many,
there are some immutable truths about the nature of the traffic. Because
of the one way source to receiver flow of multicast,
it's not in any way transactional.
There aren't any TCP‑based multicast applications, and receivers do
not send traffic back upstream to the source.
If using a many‑to‑many model,
the application itself could be both a source and a receiver. And if the
application were written in such a way as to utilize receive data when
sending, this could seem to be transactional.
However, it would be an incorrect way to think about multicast traffic itself.
This is important to understand and a major limitation of
multicast, in general. Multicast, in all cases,
is a one way source to receiver flow.
Let's move on to the next section where we'll look at sources and receivers in detail.