Confirming source-routed multicast is dead on the public Internet

Its tought to prove a negative. I'm extremely confident the answer is yes, public internet multicast is not viable. I did all the google searches, check all the usual CAIDA and ISP sites. IP Multicast is used on private enterprise networks, and some ISPs use it for some closed services.

I got sent back with a random comment from a senior official saying "but I heard different." I bit my tongue, and said I would double (now quadruple) check.

If any ISPs have working IP source-routed multicast on the public Internet that I missed, or what I got wrong. That's what content distribution networks (cdn's) are for instead.

From a technical perspective, yeah, that’s right, but as you say, tough to prove a negative. If you want to give them a “why” it doesn’t work, Zhi-Li Zhang and I wrote that up fifteen years ago, when it became evident that it wasn’t going to happen.

https://www.pch.net/resources/Papers/multicast-billing/multicast-billing-v10.pdf

                                -Bill

Hi Sean,

I'm sure that transit providers with whom you have no commercial
relationship are happy to let you program their routers to forward
your multicast packets. Not just happy, ecstatic I'd say.

Regards,
Bill Herrin

From a technical perspective, yeah, that’s right, but as you say, tough to prove a negative. If you want to give them a “why” it doesn’t work, Zhi-Li Zhang and I wrote that up fifteen years ago, when it became evident that it wasn’t going to happen.

https://www.pch.net/resources/Papers/multicast-billing/multicast-billing-v10.pdf

                               -Bill

head-thunk

Source-Specific Multicast

Never post while extremely frustrated.

AS 2914 is working to fully dismantle all its Internet multicast related
infrastructure and configs. All MSDP sessions have been turned off, we have
deny-all filters for the multicast AFI, and the RPs have been shut down.

For years we haven’t seen actual legit multicast traffic. Also the
multicast “Default-Free Zone” has always been severely partitioned. Not all
the players were peering with each other, which led to significant
complexity for any potential multicast source.

Reasoning behind turning it off is that it limits the attack surface
(multicast can bring quite some state to the core), reduces the things we
need to test and qualify, and by taking this off the RFPs we can perhaps
consider more vendors.

However, as you noted; multicast within a single administrative domain
(such as an access network distributing linear TV), or confined to
purpose-built L3VPNs very much is a thing. On the public Internet multicast
seems dead.

Kind regards,

Job

It is hard to prove a negative.

So let’s prove a positive. One of the largest (2nd largest?) transit networks on the planet just affirmatively stated they filter at their border. It is now possible to state that multicast is not ubiquitous on the Internet.

If any other large transit network (L3, GTT, HE, Cogent, etc.) would like to confirm they filter at their borders as well, that would put the final nail in the coffin.

other than billing problem, is there any other reasons why multicast would not be viable for public internet ?

Mankamana

As you all have said, to confirm, I use ssm Mcast to distribute TV from satellite down links in the headend, out to a few different remote head ends. From there it's converted back to RF video and sent to subscribers via cable or hfc plant

Aaron

Can your hfc customers do an igmp join?

No? Then it's probably not considered "public".

-Steve

Thus spake Mankamana Mishra (mankamis) via NANOG (nanog@nanog.org) on Wed, Aug 01, 2018 at 02:43:10AM +0000:

other than billing problem, is there any other reasons why multicast would not be viable for public internet ?

Hi Mankamana,

You can find a reasonable overview here with respect to ASM:

Dale

Two other significant contributing factors stem from complexity and
security issues.

Here are some references I'm familiar with:

  <https://www.nanog.org/meetings/nanog21/presentations/eubanks.ppt>
  <https://www.nanog.org/meetings/nanog35/presentations/kristoff.pdf>
  <https://www.cymru.com/jtk/tmp/secure-junos-mcast.html>

The last link was briefly maintained on Team Cymru's production template
section, but it looks it is now gone and like this is the last copy of
it I had before it was published a few years ago.

John

I can confirm that GTT does indeed filter IP sourced from 224.0.0.0/4 at its edge.

Do you mean sent to 224/4 or literally anything with a source address
of 224/4?

For those that are or are considering filtering, you might also want to
consider limiting IGMP at router interfaces. The only known use of
IGMP past the local link I'm aware of was for mtrace tool, but allowing
it can pose some danger in two forms. One is yet another DDoS
reflection and amplification vector, another is a some router system
and configuration disclosure. See the following for details:

  <https://ccronline.sigcomm.org/wp-content/uploads/2017/01/p27-sargent.pdf>

In experiments I ran in early parts of that work I found that Cogent
did not forward IGMP messages through its network in my tests, but this
may be due to the routing hardware/software they were using at the time
rather than an explicit filtering policy.

John

Hey Mankamana,

other than billing problem, is there any other reasons why multicast would not be viable for public internet ?

Imagine someone like youtube or netflix would like to use multicast,
instead of caches. They'd need to start new multicast stream for every
content with small delay (to get more viewers on given stream), how
much delay would consumer tolerate before content starts? 1min? 5min?
So every minute or every 5 minute new stream of movie would be sent,
except it would need to be sent many times, for each bitrate
supported.
Each of these streams is wide (wider than unicast) HW state that needs
to be stored on every device on path, for unicast we only store 1
narrow HW state per destination, for multicast we store 1 wide HW
state per flow/stream, we don't have the hardware to do that, if there
would be any significant demand for multicast.
It only works when there is no use-case for it, and even then, it's
insecure DoS vector.

I'm aware that multicast is used extensively for "closed enterprise" networks in the financial and media industries. It seems to work well when a single organization is paying for the entire network.

My executive official came from that background, so I get why someone from that world would think multicast is widely used. Asking enterprise network sales people, they keep saying Yes, of course we support multicast.

That's why I wanted to hear from public Internet engineers if multicast was still viable on the *public Internet*.

I'd say no - even though we have done inter-AS multicast before, it's only
been with our direct peers.

What if... Bear with me for a moment here, we don't try to force VoD onto a
multicast setup? Multicast is used extensively by all major ISPs(if they
have the rights) to deliver IPTV. One issue you brought up is people
unwillin to wait 1 or 5 mins for a show, well before the days of youtube
people waited weeks for OTA programming that started with or without delay,
depending on how many relays you were going through. As a use case of
multicast over the internet, a Real time TV rebroadcaster would be a really
good use case. The federal govt already subsidises super expensive energy
hogging TV broadcast towers, who's to say they wouldn't prefer it to just
go over the interwebs? Bit rate's not a problem, a 720i stream takes 1 or 2
mbps, which is a fraction of a home broadband connection(25mbps down 3 up,
last time i checked). I think we all on nanog would agree internet is more
important than TV. Govt money might better be spent on a better internet
than TV radios. Of course that might mean some internet backbone
upgrades(maybe even govt subsidised upgrade), but i would never say that
there isn't a commercial use case for it.

Personally, I think the use case is a lot stronger for multi-person video conferencing.

Miles Fidelman

hey,

What if... Bear with me for a moment here, we don't try to force VoD onto a
multicast setup? Multicast is used extensively by all major ISPs(if they
have the rights) to deliver IPTV.

We are an IPTV provider in europe and we definetly see share of linear TV (that we are delivering via intra-AS multicast today) decreasing YOY.

OTT plays a big part but even more customers use our own on-demand services including network PVR.

Numbers don't add up yet but in 3-4 years even the intra-AS multicast will not make sense for us any more, easier/better to deliver everything via unicast.