All things related to multicast

[Greg Shepherd <>]

On Mon, 7 Jul 2003, David Meyer wrote:

> >> >  No ISP/carrier that I have ever worked for (or even, that
> >> >  I know of, where ISP == "IP Transport Bandwidth
> >> >  Provider") has ever been able to demonstrate any kind of
> >> >  CAPEX savings due to multicast. In fact, the places where it
> >> >  might be most useful (tail circuits) provide the opposite
> >> >  incentive to the bandwidth provider (why would I provide
> >> >  you a technology that allows you to buy less of my
> >> >  product [bandwidth]?)
> >>
> >> As Lenny pointed out, any 'savings' assumes canabilizing unicast content
> >> for multicast. BUT a large-audience multicast transport service could
> >> bring a whole new range of content at a much higher quality (read
> >> bit-rate) which could be a completely different service to
> >> sell.
>
>       So you are saying that you have a technology that is
>       looking for a "whole new range of content at a much
>       higher quality"?  OK. I don't disagree that multicast is
>       a technology looking for such an application (at least in
>       the inter-domain space; we all know that there are many
>       enterprise applications).

I think there are already plenting of applications. As we, the choir, have
been preaching to ourselves for years, this must be content driven in that
its the content owners who stand to benifit from a multicast transport biz
model.

> >> Its not about saving bandwidth in the core.
>
>       Yes. History and experience has shown us that this much
>       is clear.
>
> >> Its about creating a transport service which allows
> >> successfull biz-models/services for content owners which are
> >> ISP customers.
>
>       could/would/should/...As we all know, this whole
>       discussion is 10+ years old. I really don't see anything
>       new here.

Good point! ...and that is the problem. So I guess you're saying that we
need something new?

As I stated in the BOF overview, I would just like to describe the problem
collectively. We can then turn to if/how it can be solved - either by
putting together existing pieces or creating some missing piece. But we
have to start by agreeing on the problem, AND agreeing on what a solution
should achieve.

Thanks,
Greg

> >> Having profitable customers is a good thing.
>
>       I don't think any one is arguing that profitability isn't
>       a good thing (or if they were, I didn't undertstand that
>       from the thread).
>
> >> >  OTOH, perhaps that's a selling point when marketing to
> >> >  large content providers or the like. The reality,
> >> >  however, is that such custmers (and in fact, most large
> >> >  consumers of b/w) want carrier diverse facilities, kinda
> >> >  blowing away that argument in any event. Clearly there
> >> >  are cross-incentives here.
> >>
> >> Yup, I've seen the same. But I also think a large content owner wants
> >> first the largest audience possible.
>
>       This would seem to be the case if there is a positive
>       correlation between maximizing ROIC and/or minimizing
>       OPEX, and audience size. It is not clear (at least not
>       clear to me) that this is necessarily the case.
>
> >> > >> obviously if all the users using simultaneous unicast switched to
> >> > >> multicast this MIGHT be true, but the real point is that it enables
> >> > >> new sources, applications and services, and might therefore INCREASE
> >> > >> revenue....noone can say for sure...
> >> > >>
> >> > >> i think the technical obstacles (cable tv modem head end, DSLAM, and
> >> > >> other minimal support for igmp magic, security, charging for group
> >> > >> size and other stuff are the critical points and think this BOG Is 
> >> > >> an
> >> > >> althogether
> >> > >> Most Exellent Idea
> >> >
> >> >  Yep.
> >>
> >> Thanks for your support Dave,
>
>       Sure. Hopefully we can tackle some of the thorny problems
>       that have plagued multicast deployment (and have been
>       pointed out in this thread).
>
>       Dave
>