Hacker News new | ask | show | jobs
by tialaramex 2782 days ago
Unicast is sending messages to a single peer. Broadcast is sending messages to everybody. Multicast is in between, sending to some arbitrary set of recipients.

On a Local network, multicast is very easy to do. Unless it's very, very old your computer almost certainly uses multicast on local networks already, for a variety of purposes. A dumb old network just sent all packets to all computers on the local network, so both broadcast and multicast were equally easy to do, your network card has a filter built into it, that autonomously weeds out messages your computer cares about, and ignores the others - so the Operating system is like "Hey, network card, my unicast address is 10.20.30.40, and I am also listening to multicast address 224.0.0.251" and it will just throw away any packets that aren't for those addresses. A smart modern network (e.g. the mid-range gigabit switch serving your desk at work) keeps track of which addresses are where and sends copies of messages only to where they seem useful, leaving more network bandwidth for everybody else.

The Internet can in theory do Multicast too. I've used this to, for example, watch television with a dozen other people without any copy of the TV picture data being sent over the shared data link to us more than once. That's what those addresses are for, you "Join" one of the multicast addresses and begin receiving, say, the Olympics live.

However making all this work is hard, and in most places, most of the time, nobody puts in all that hard work, so probably you'll find that although local network multicast works for you (as I said it's used in modern systems) you cannot use the Internet's multicast features. Which is a shame, but we can't have nice things.

2 comments

The technical explanation of multicast is quite good. But the reason it isn't available on the internet has nothing to do with the technical hurdles.

It isn't used because of the economics behind the ISP business.

With multicast a single sender can have arbitrary many receivers but sends its data only once. The network infrastructure 'clones' than that data on its way to the receivers as necessary. But that's not in line with the economic interests of an ISP.

With unicast the sender has to use increasingly more bandwidth when he wants to reach more receivers, and the ISP gets payed for that additional bandwidth. The more bandwidth the sender uses the more money makes the ISP. With multicast on the other hand the sender needs to send everything only once no mater how many receivers are listening.

Imagine you could send an audio or video stream to potentially everyone with internet access in the whole world but would need to pay only for the bandwidth of exactly one stream. That would be very nice for you, or Spotify, or Netflix, but not such a good deal as the current one for your ISP.

That's why ISPs don't sell multicast connectivity. Technically it would be easy. The current network-infrastructure would be able to handle multicast (almost) without any additional effort on the carrier side. After all the technology is build in in almost every switch or router for years now. Live streaming of AV media would be possible for everyone with internet access. One would not need the bandwidth of say YouTube to reach as many receivers as they do. But that will never happen because ISPs just aren't interested in providing multicast connectivity!

> Imagine you could send an audio or video stream to potentially everyone with internet access in the whole world but would need to pay only for the bandwidth of exactly one stream. That would be very nice for you, or Spotify, or Netflix, but not such a good deal as the current one for your ISP.

This mostly happens with Akamai [1] and Netflix [2] CDN appliances on edge networks though (content caching boxes used to offload transit or peering fabric traffic). I'd argue Multicast didn't take off because of "tragedy of the commons" issues; ISPs don't want to support additional complex network routing technologies (at additional, substantial cost) when existing one to many unicast solutions (mentioned above) are sufficient.

[1] https://www.akamai.com/us/en/multimedia/documents/akamai/aka...

[2] https://media.netflix.com/en/company-blog/how-netflix-works-...

There's also the argument that few people want it, because multicast is only useful for synchronized streams.

Netflix, Spotify, and other services with on-demand content couldn't use it unless they made the service worse by forcing viewers to wait for a multicast.

I bet they'd still have significant savings if they made everyone wait in 5-second lapses.

Pausing and resuming elsewhere would mean changing to a different multicast stream or starting a new one if there weren't any before.

Internode and iiNet (at least) in Australia did multicast IPTV for a while over ADSL2.

https://forums.whirlpool.net.au/archive/2521333

you make a good argument against usage based billing
Because capitalism.

Also:

We have the technology! But capitalism.

not even. more like "we've got a model that making us lots of money, lets not change just because some people keep whining about 'efficiency' and 'democratization'"
Before there was YouTube, there was MBone, a way to syndicate multicast content across the web. With multicast, in theory millions of subscribers can watch a video streamed from a single laptop (as long as they all watch in sync).

https://en.m.wikipedia.org/wiki/Mbone