Re: Confirming source-routed multicast is dead on the public Internet

[Mark Tinka]

On 1/Aug/18 19:43, Tarko Tikan wrote:

>  
>
> 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.

I fully expect this to trend.

In Africa, linear (pay) TV is on the down every month, and the only
reason it's mostly still seeing some patronage is because of the sports
channels which "cannot be" unbundled from the full package. The other
reason it's still marginally alive is because of customers that can't
spare enough "data" to do the majority of their entertainment online.

I know several power users that have deliberately cut the linear TV
cord, have gone fully VoD, and have managed to make arrangements to
stream sports shows in other ways.

The leading pay TV operator in sub-Saharan Africa, Multichoice (DStv)
are thinking about their future and are providing the ability for
customers to stream all of their channels online, either in real-time or
as post-aired VoD content. They've also launched ShowMax, which is their
offering to compete with Netflix, Hulu, e.t.c.

I was in Malaysia the other day, and Astro are definitely struggling
with the declining demand in their pay TV service (both satellite- and
IPTV-based).

I'm with Tarko when I say in 5 or so years, Multicast for IPTV will
begin to die off because customers will be moving more to VoD use-cases.

Mark.

Re: Confirming source-routed multicast is dead on the public Internet

[Mark Tinka]

On 1/Aug/18 00:15, Job Snijders wrote:

> 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.

I'd concur.

Mark.

RE: Confirming source-routed multicast is dead on the public Internet

[Jakob Heitz (jheitz) via NANOG]

You could put this multicast receiver into the last hop before the customer
and then send unicast to the customer.

Regards,
Jakob.


-Original Message-
From: Saku Ytti  
Sent: Thursday, August 2, 2018 2:45 PM
To: Jakob Heitz (jheitz) 
Cc: nanog@nanog.org
Subject: Re: Confirming source-routed multicast is dead on the public Internet

On Fri, 3 Aug 2018 at 00:42, Saku Ytti  wrote:

> Cute :). Well 8*bitrates, but nice optimisation to make stream count
> finite. Of course at cost of quality, as receiver needs up-speed of 8x
> at start. Interesting side-effect, quality increases as movie
> progresses :)

I may have worded up-speed potentially ambiguously, I mean over-speed,
meaning access needs higher than stream bitrate to receive stream of
specific bitrate. In practical world, of course already very
problematic scenario for most NFLX consumers.

-- 
  ++ytti

RE: Confirming source-routed multicast is dead on the public Internet

[Jakob Heitz (jheitz) via NANOG]

ok. Play 2 minutes of ads at the start and save a stream.
Play another 2 minutes of ads every 16 minutes, then the maximum number of 
streams is 4.
The ads can be received in a single stream or be received after the shorter 
streams have completed.

Regards,
Jakob.


-Original Message-
From: Saku Ytti  
Sent: Thursday, August 2, 2018 2:42 PM
To: Jakob Heitz (jheitz) 
Cc: nanog@nanog.org
Subject: Re: Confirming source-routed multicast is dead on the public Internet

Hey,

On Fri, 3 Aug 2018 at 00:36, Jakob Heitz (jheitz) via NANOG
 wrote:

> Hey, there's a better way.
> Split the movie into segments:
> Segment 1: Minute 1.
> Segment 2: Minute 2.
> Segment 3: Minutes 3,4.
> Segment 4: Minutes 5-8.
> Segment 5: Minutes 9-16.
> etc.
> Then send each segment in a loop.
> Each receiver receives every loop simultaneously.
> Each segment may start receiving part way through, but then it starts again.
> By the time a segment needs to play, it is completely received.
> A 128 minute movie needs 8 streams.
> While waiting for the first minute, you can play ads :)
> The shorter segments don't need to be sent for long:
> Receivers can stop receiving the short segments once they have received one 
> loop of it.
> When no receiver is receiving a loop, you can stop sending it.

Cute :). Well 8*bitrates, but nice optimisation to make stream count
finite. Of course at cost of quality, as receiver needs up-speed of 8x
at start. Interesting side-effect, quality increases as movie
progresses :)
-- 
  ++ytti

Re: Confirming source-routed multicast is dead on the public Internet

[Saku Ytti]

On Fri, 3 Aug 2018 at 00:42, Saku Ytti  wrote:

> Cute :). Well 8*bitrates, but nice optimisation to make stream count
> finite. Of course at cost of quality, as receiver needs up-speed of 8x
> at start. Interesting side-effect, quality increases as movie
> progresses :)

I may have worded up-speed potentially ambiguously, I mean over-speed,
meaning access needs higher than stream bitrate to receive stream of
specific bitrate. In practical world, of course already very
problematic scenario for most NFLX consumers.

-- 
  ++ytti

Re: Confirming source-routed multicast is dead on the public Internet

[Saku Ytti]

Hey,

On Fri, 3 Aug 2018 at 00:36, Jakob Heitz (jheitz) via NANOG
 wrote:

> Hey, there's a better way.
> Split the movie into segments:
> Segment 1: Minute 1.
> Segment 2: Minute 2.
> Segment 3: Minutes 3,4.
> Segment 4: Minutes 5-8.
> Segment 5: Minutes 9-16.
> etc.
> Then send each segment in a loop.
> Each receiver receives every loop simultaneously.
> Each segment may start receiving part way through, but then it starts again.
> By the time a segment needs to play, it is completely received.
> A 128 minute movie needs 8 streams.
> While waiting for the first minute, you can play ads :)
> The shorter segments don't need to be sent for long:
> Receivers can stop receiving the short segments once they have received one 
> loop of it.
> When no receiver is receiving a loop, you can stop sending it.

Cute :). Well 8*bitrates, but nice optimisation to make stream count
finite. Of course at cost of quality, as receiver needs up-speed of 8x
at start. Interesting side-effect, quality increases as movie
progresses :)
-- 
  ++ytti

Re: Confirming source-routed multicast is dead on the public Internet

[Jakob Heitz (jheitz) via NANOG]

Hey, there's a better way.
Split the movie into segments:
Segment 1: Minute 1.
Segment 2: Minute 2.
Segment 3: Minutes 3,4.
Segment 4: Minutes 5-8.
Segment 5: Minutes 9-16.
etc.
Then send each segment in a loop.
Each receiver receives every loop simultaneously.
Each segment may start receiving part way through, but then it starts again.
By the time a segment needs to play, it is completely received.
A 128 minute movie needs 8 streams.
While waiting for the first minute, you can play ads :)
The shorter segments don't need to be sent for long:
Receivers can stop receiving the short segments once they have received one 
loop of it.
When no receiver is receiving a loop, you can stop sending it.

Regards,
Jakob.


-Original Message-
Date: Wed, 1 Aug 2018 19:24:21 +0300
From: Saku Ytti 

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.

Re: Confirming source-routed multicast is dead on the public Internet

[Sean Donelan]

On Thu, 2 Aug 2018, John Levine wrote:

In article  you 
write:

Multicast is being used in various private IP networks. It seems to work
very well for satellite content distribution because multicast doesn't
require ack's. Enterprise networks also use multicast.


I would think it'd work fine on private networks, but since there's no
authentication, on the public Internet how could you tell the
multicast you want from random malicious junk on the same IP address?


They use some type of encryption to authenticate the data.

Satellite distribution networks usually encrypt both the satellite signal 
so only authorized receivers get the download. The multicast data files 
are also separately encrypted/signed/checked.


On private/enterprise networks, I guess they just trust its a controlled 
network.


On the public Internet. Gosh darn, I don't know, shrug?

Re: Confirming source-routed multicast is dead on the public Internet

[John Levine]

In article  you 
write:
>Multicast is being used in various private IP networks. It seems to work 
>very well for satellite content distribution because multicast doesn't 
>require ack's. Enterprise networks also use multicast.

I would think it'd work fine on private networks, but since there's no
authentication, on the public Internet how could you tell the
multicast you want from random malicious junk on the same IP address?

Re: Confirming source-routed multicast is dead on the public Internet

[Sean Donelan]

Thanks to everyone that helped.  Off-list I heard from network engineers 
at several global Internet providers. They all confirmed that multicast 
is no longer supported on their public Internet backbones, no matter what 
their sales people might say. If someone opened a multicast trouble 
ticket, likely no one in their NOC would know what to do with it. They 
acknowledged there might be some old multicast configs on Internet facing 
routers, and eventually they'll clean those out.


Backbone network engineers are fairly blunt.

Multicast is being used in various private IP networks. It seems to work 
very well for satellite content distribution because multicast doesn't 
require ack's. Enterprise networks also use multicast.

Re: Confirming source-routed multicast is dead on the public Internet

[Saku Ytti]

On Wed, 1 Aug 2018 at 20:47, Saku Ytti  wrote:

> I'm sure both of your use cases are used extensively in internal
> network. I've worked for company who distributed broadcast TV on their
> MPLS IP backbone, two-plane network, red and blue, one copy for each
> tv channel on both planes and far-end drops redundant copy. Very
> attractive solution commercially for client and provider. But no
> potential for global scale.

Just to clarify what I mean by 'broadcast TV', these streams were not
received by set-top boxes receiving IP packets. End-users were
cable/antennae users, 'client' was receiving the content at antennae
site to be transmitted over air.
Classically these are separate purpose built networks, which are very
expensive, so in this particular case everyone won, except the legacy
provider who was billing for the purpose built network.

-- 
  ++ytti

Re: Confirming source-routed multicast is dead on the public Internet

[Saku Ytti]

Hey Miles and Michael,

It is entirely fair to debate what the use-case would be, the
underlaying technical problem remains the same, if it becomes useful
(globally) we don't have the hardware to cater for it.

I'm sure both of your use cases are used extensively in internal
network. I've worked for company who distributed broadcast TV on their
MPLS IP backbone, two-plane network, red and blue, one copy for each
tv channel on both planes and far-end drops redundant copy. Very
attractive solution commercially for client and provider. But no
potential for global scale.


On Wed, 1 Aug 2018 at 20:44, Miles Fidelman  wrote:
>
> On 8/1/18 12:24 PM, Saku Ytti wrote:
>
> > 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.
> >
> Personally, I think the use case is a lot stronger for multi-person
> video conferencing.
>
> Miles Fidelman
>
> --
> In theory, there is no difference between theory and practice.
> In practice, there is.   Yogi Berra
>


-- 
  ++ytti

Re: Confirming source-routed multicast is dead on the public Internet

[Tarko Tikan]

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.


--
tarko

Re: Confirming source-routed multicast is dead on the public Internet

[Miles Fidelman]

On 8/1/18 12:24 PM, Saku Ytti wrote:


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.

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


Miles Fidelman

--
In theory, there is no difference between theory and practice.
In practice, there is.   Yogi Berra

Re: Confirming source-routed multicast is dead on the public Internet

[Michael Crapse]

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.


On 1 August 2018 at 10:24, Saku Ytti  wrote:

> 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.
>
> --
>   ++ytti
>

Re: Confirming source-routed multicast is dead on the public Internet

[Hunter Fuller]

On Wed, Aug 1, 2018 at 11:27 Sean Donelan  wrote:

> On Wed, 1 Aug 2018, Aaron Gould wrote:
> > 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
>
> 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.

Re: Confirming source-routed multicast is dead on the public Internet

[Sean Donelan]

On Wed, 1 Aug 2018, Aaron Gould wrote:
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


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*.

Re: Confirming source-routed multicast is dead on the public Internet

[Saku Ytti]

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.

-- 
  ++ytti

Re: Confirming source-routed multicast is dead on the public Internet

[Justin M. Streiner]

On Tue, 31 Jul 2018, John Kristoff wrote:


Second best might be the Internet2 community where a number of
institutions that have always had it might still have it turned on.
Though there has been only one post in all of 2018 on their list if
that tells you anything.


At my previous job (large .edu), we spoke MSDP with Internet2 through our 
regional I2 connector, however we turned that MSDP session off probably 
two years ago, and I don't think that session moved any useful traffic for 
probably two years before that.  Multicast was used extensively within our 
network, but nothing outside for quite a while.


I agree with general sentiment that multicast across the larger Internet 
is dead.


Thank you
jms

Re: Confirming source-routed multicast is dead on the public Internet

[John Kristoff]

On Wed, 1 Aug 2018 15:45:44 +
Adam Davenport  wrote:

> 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:

  

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

Re: Confirming source-routed multicast is dead on the public Internet

[Adam Davenport]

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

On 7/31/2018 6:44 PM, Patrick W. Gilmore wrote:

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.

Re: Confirming source-routed multicast is dead on the public Internet

[John Kristoff]

On Wed, 1 Aug 2018 02:43:10 +
"Mankamana Mishra (mankamis) via NANOG"  wrote:

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

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

Here are some references I'm familiar with:

  
  
  

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

Re: Confirming source-routed multicast is dead on the public Internet

[Dale W. Carder]

Thus spake Mankamana Mishra (mankamis) via NANOG (nanog@nanog.org) on Wed, Aug 
01, 2018 at 02:43:10AM +:
> 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:
https://tools.ietf.org/html/draft-acg-mboned-deprecate-interdomain-asm-02

Dale

Re: Confirming source-routed multicast is dead on the public Internet

[Mankamana Mishra (mankamis) via NANOG]

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

Mankamana 

> On Jul 31, 2018, at 2:36 PM, Bill Woodcock  wrote:
> 
> 
> 
>> On Jul 31, 2018, at 2:28 PM, Sean Donelan  wrote:
>> 
>> Its tough to prove a negative. I'm extremely confident the answer is yes, 
>> public internet multicast is not viable.
> 
> 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

Re: Confirming source-routed multicast is dead on the public Internet

[Steve Meuse]

Can your hfc customers do an igmp join?

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

-Steve

On Wed, Aug 1, 2018 at 5:21 AM Aaron Gould  wrote:

> 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
>
> > On Jul 31, 2018, at 5:15 PM, Job Snijders  wrote:
> >
> >> On Tue, 31 Jul 2018 at 23:29, Sean Donelan  wrote:
> >>
> >> 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.
> >
> >
> >
> > 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
>
>

Re: Confirming source-routed multicast is dead on the public Internet

[Aaron Gould]

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

> On Jul 31, 2018, at 5:15 PM, Job Snijders  wrote:
> 
>> On Tue, 31 Jul 2018 at 23:29, Sean Donelan  wrote:
>> 
>> 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.
> 
> 
> 
> 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

Re: Confirming source-routed multicast is dead on the public Internet

[Bill Woodcock]

> On Jul 31, 2018, at 2:28 PM, Sean Donelan  wrote:
> 
> Its tough to prove a negative. I'm extremely confident the answer is yes, 
> public internet multicast is not viable.

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


signature.asc
Description: Message signed with OpenPGP

Re: Confirming source-routed multicast is dead on the public Internet

[Patrick W. Gilmore]

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.

-- 
TTFN,
patrick

> On Jul 31, 2018, at 15:15, Job Snijders  wrote:
> 
> On Tue, 31 Jul 2018 at 23:29, Sean Donelan  wrote:
> 
>> 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.
> 
> 
> 
> 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

Re: Confirming source-routed multicast is dead on the public Internet

[John Kristoff]

On Tue, 31 Jul 2018 21:28:31 +
Sean Donelan  wrote:

> 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.

More anecdotal evidence.

Probably the best place to know what is going on with multicast is on
the mboned list (yea that still exists):

  

Second best might be the Internet2 community where a number of
institutions that have always had it might still have it turned on.
Though there has been only one post in all of 2018 on their list if
that tells you anything.

There is almost no public multicast monitoring anymore.  Practically
all dead.  You could poke around the I2 router proxies and see what is
happening on some of the last of the remaining IP multicast-enabled
Internet (hint, mostly noise from odd devices that have strayed outside
the local institution):

  show multicast routes
  show pim join 
  ...

I keep hearing about some research project in the deep blue sea that
uses it.  You might find a small amount of it out there, but I'd bet
overall its usage is teeny tiny and limited to a shrinking number of
networks.  Turned off interdomain multicast when I returned here in
2016.

John

Re: Confirming source-routed multicast is dead on the public Internet

[Job Snijders]

On Tue, 31 Jul 2018 at 23:29, Sean Donelan  wrote:

> 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.



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

Re: Confirming source-routed multicast is dead on the public Internet

[Sean Donelan]

head-thunk

Source-Specific Multicast


Never post while extremely frustrated.

Re: Confirming source-routed multicast is dead on the public Internet

[Bill Woodcock]

> On Jul 31, 2018, at 2:28 PM, Sean Donelan  wrote:
> 
> Its tough to prove a negative. I'm extremely confident the answer is yes, 
> public internet multicast is not viable.

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


signature.asc
Description: Message signed with OpenPGP

Re: Confirming source-routed multicast is dead on the public Internet

[William Herrin]

On Tue, Jul 31, 2018 at 5:28 PM, Sean Donelan  wrote:
> 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.

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


-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Dirtside Systems . Web: