Re: [MBONED] deprecating MSDP

[Toerless Eckert <[e-mail]>]

Great uplevel, Mikael

IMHO its still worthwhile to brainstorm what an initial IP multicast service
"across the internet" would need to have any change to be adopted/used,
even if only to understand that the problem is not just solved by
"Just use SSM".

here's my best theory what could work:

Get an initial SSM service deployed into Tier 1 SP, available to 10++
million subs:

  - Avoids initial considerations for interdomain transit
  - Creates criticial mass to encourage app developers to support it.

Apps "just" need to support SSM API and congestion control aka RFC8085.
Eg: fountain/network codecs. SSM is easy, the rate adaption is quite advanced.

Operators can not trust that apps perform complint to RFC8085. Most
easily, initial SSM multicast would be in a scavenger class. Makes
all bandwidth used by it free for the SP. Hopefully good enough to make
marketing folks in SPs interested.

(S,G) state in network need to be controlled. On receiver edge,
receivers must only be permitted to join to few # of active (S,G) state.
Else networks can be killed with receiver (S,G) state. This ultimately is
introducing a requirement for some active (S,G) awareness into receiver
edge devices.

Senders should be be a chargeable service option. IMHO charging
for senders hould be handled like SMS was handled in Germany in the
90'th: Make it virtually free first and raise the bar once the junkies,
oops: subscribers can not live without it. Might want to charge some
entrance fee even day 1 to get only senders that have a real business
inererst and large number of receivers (instead of a repetition of
"cameras all over the world").

Cheers
    Toerless

On Wed, Sep 06, 2017 at 08:33:48AM +0200, Mikael Abrahamsson wrote:
> On Tue, 5 Sep 2017, Manfredi, Albert E wrote:
> 
> >default. I'm also informed, second hand I'll admit, that ISPs and
> >CDNs do not much favor multicast, for their own technical and
> >economic reasons. I suppose one reason might be the proliferation
> >of streaming media protocols these days, specific to different
> >devices, which defeats the purpose of multicast.
> 
> There are lots of benefits to using multicast, it's just that there
> are also drawbacks. You can run an imperfect network (0.1% packet
> loss) any few will notice as long you run unicast. As soon as you
> introduce multicast, most applications that an ISP might be
> interested in (generally linear TV), now all of a sudden you need a
> network that has 1 in million packet loss, you run into gnarly fault
> finding cases, you need network verification tools to make sure
> you're assuring quality over time, etc.
> 
> Running a unicast-only network is quite forgiving, running multicast
> for what people typically use multicast for in an ISP network, is a
> lot less forgiving. Upside is typically small, unless you're
> providing TV for a profit (I don't know of any other typical
> residential ISP revenue stream for multicast), it's just not worth
> it.
> 
> -- 
> Mikael Abrahamsson    email: [e-mail]
> 
> _______________________________________________
> MBONED mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mboned

-- 
---
[e-mail]