RE: multicast (was Re: Readiness for IPV6)

Mailman List Mirror (Read Only)
1

Cynical/realist, it's a fine line.

While p0rn does drive a lot of the utilization on the net, I doubt that
the those content providers are going to be happy with sending their
content un-protected across the net for anyone (paying or not) to see.
So now you are into a encryption issue where you need to insure the
receiving end can securely receive the encryption key and not share it.
Not insurmountable, but not (that I'm aware of) possible with today's
applications.

The upshot is today's client applications need to grow to add these and
other discussed features and functions to help the content providers.

David

2

Here's my $0.02 on the whole multicast thing. We've been at this
for a number of years now, and robust, ubiquitous multicast
on the internet is really nowhere in sight. Kind of sounds like
QoS, and maybe there's a lesson there (20 years of research and
IETF activity, yielding, well, what?).

Given the amount of time and resource we've spent on multicast,
the question one might ask is "why hasn't multicast succeeded"?
My guess is that it is because the demand from any of the
potential users of the service just isn't there (not at internet
scales, at least not now). Add to this that there are other,
possibly simpler mechanisms to accomplish much of the
functionality that multicast envisions (e.g. application layer
multicast; this even hits dial-up eyes with no modification),
problems with billing models, and difficultly in deploying the
existing set of protocols (too much complexity, broken
architecturally on shared access exchanges, etc), and you might
expect just about what we've experienced.

Dave

3

Thus spake "David Meyer" <dmm@sprint.net>

Here's my $0.02 on the whole multicast thing. We've been at this
for a number of years now, and robust, ubiquitous multicast
on the internet is really nowhere in sight. Kind of sounds like
QoS, and maybe there's a lesson there (20 years of research and
IETF activity, yielding, well, what?).

OTOH, multicast and QOS are both widely deployed inside most large corporate
networks and are rapidly approaching ubiquity. They both effectively solve
business problems and therefore there's a big motivation for them, and the
IETF's efforts have been extremely fruitful. Don't let the IETF's (or NANOG's)
ISP-centric membership blind you to that.

S

4

Given the amount of time and resource we've spent on multicast,
the question one might ask is "why hasn't multicast succeeded"?

Has it not ? It is succeeding in every place where you have a closed
financial business model from content to eyeball. It is purely failing
to be established as a network connectivity infrastructure component
by access ISPs because these access ISPs do not invest in their own
future if you ask me.

If we would have had the same business model driven network infrastructure
and technology deployment politics that we have today in the beginning of
the 1990th then we would not have the Internet==TheWeb today. Luckily at
that time the IP unicast infrastructure was expanded predominantly by
research, academic and other public funding (DoD, ES, NSF, etc..) so that
we reached a critical mass of eyballs that made the upcoming technology of
the web viable enough to get businesses jumpstarted into that web technology.
And see where it is today.

IP multicasts main intrinsic downside is that it is not a good transitional
technology today. This means that you first must provide for a critical mass
of eyballs before you will get new content using it. Who did jumpstart
the web with content ? The incumbant book stores, CD dealers
or retailers ? No, of course not. It was new content. The incumbants had an
established infrastructure, thank you very much, i am making lots of money
out of analog cable-tv at dismal quality, go away with new technology.

Did the web startups have the money to demand the establishment of the
Internet infrastucture ? No, not in the beginning - only after the ralley
set off. It just kicked off by the initial pre-web user basis and grew from
there on. And see what growth curve it got. Don't tell me you wouldn't want
to repeat that again - and this time you'll all sell your stock at the
ideal time, right ;-)) ?

Who today can do streaming media across the Internet ? Well, mostly the
big players because the financial overhead in using overlay networks is way
too high. How progressive are the big players ? Well... how about the
music industry. Where would we be with streaming audio in the Internet
if it was not for Napster ? So right, there is starting to be some movie-on
demand download now. Is it attractive ? Well... we can argue that for a
long time, but in the endthe new technology is the best chance for new
content and/or new providers, not necessarily to replace incumbant
solutions - because for incumbant solutions everybody just makes a cost
comparison, and that's a much longer term goal to reach once you already
have a paid off infrastructure in place.

With ip multicast as an end-to-end transport component you could repeat
the success model of the web for streaming content to large number of
receivers. Think about the anybody startup who could broadcast a streaming
video to arbitrary many people like he could back in 1995 reach 'arbitrary'
many people with this "web" thing application. If we would have let's
say 10 mio eyeballs @ home that reliably could get ip multicast, then
this would be a critical mass for smaller content providers to start out
providing content for them.

Why is it not happening ? See above: Because investment in ISPs today is
driven by marketing and marketing is driven purely by the "solution" buzzword.

IP multicast is not a solution in itself, it is a technology.
If you have a business case with an application, content, control the whole
path and have the eyeballs - then you have a solution, otherwise you just have
a piece of the infrastructure. But those business cases are always individual
ones, and even though they can be big and successfull (like in the finance
markets or upcoming in enterprise ip multicast transit), you will often not
even know afterwards that IP multicast is used in them and that over time
leaves a totally skewed picture on the success of ip multicast.

And we don't really talk about these business specific solutions that
IP multicast thrives from today. What we talk about here is the
main and open ended promise of IP multicast as a ubiquitous network
transport component in the ISP transit space, right ? This open ended
promise is exactly what we have seen to play out so well with IP unicast
and the web. How do you get this open ended message into marketing heads and
repeat it for ip multicast ? I don't know: IP multicast has been around for
too long, so it is not a marketing buzzword anymore, and sound investment
into infrastucture components is not on the agenda of access ISPs. FUD rules.

My guess is that it is because the demand from any of the
potential users of the service just isn't there (not at internet
scales, at least not now).

Think 1995, think web. What demand ? How do you measure demand, how can
you predict demand ? You generate hype ? "There is no demand" is just
backward looking:

"I do not have eggs. I do not need need chicken. What the heck do i know
  wether eggs would taste better than spam. I do not want eggs, let me
  eat spam"!

And even worse, people don't know what eggs are. They only want omolettes!
(Multicast ? Huh ? give me live streaming radio and video, on-line on-demand
music, software and video download for this weeks hippest product,
stock ticker for my dad and large scale interactive multiplayer gaming
with short latencies, that's what i want. What was this multicast stuff again
?)

Add to this that there are other,
possibly simpler mechanisms to accomplish much of the
functionality that multicast envisions (e.g. application layer
multicast; this even hits dial-up eyes with no modification),

Simpler for certain business cases, like when you have an obsolete
infrastructure that is entangled in all kind of legacy conditions,
sure. IP Multicast was never designed as the ideal transition solution.

If we would have listened to this transition argument back in the 1980th
then we today would not have IP at all, but just applications
that have to be commissioned by national PTTs running on top of
X25 over ATM or the like. Ridiculous ? Well, look what processes are
involved in provisioning a live video stream into the Internet with
overlay networks then you know what i mean. Free choice of the receiver ?
It's closer to the frustration you have as a cable-tv customer in getting
200 useless channels but guaranteed not the 5 ones you want.

problems with billing models,

FUD. What problem with billing models ? If you are an ISP, you are selling
bandwidth. If another receiver joins the content , you get another piece of
egress bandwidth filled up which hopefully is being paid for. If you need
to cross-charge this back to the ingress-point, so do it. You just
technically can't simply have accounting points on your exchange points
anymore if you need to do so, you also need them on the delivery side of
your network. More complex things than this have been done in the past.
And of course, that could even be improved if demand for technology
improvements was there (like eyeball count transmission via PIM).

existing set of protocols (too much complexity, broken
architecturally on shared access exchanges, etc)

Just do SSM if you are troubled by complexity of protocols.

And besides: I never got the impression that technical complexity issues are
decisive for the success or lack thereoff: It is the missing drive from
marketing at the places connecting to eyeballs. Marketing only buys complete
solutions nowadays with lots of recent buzzwords per square inch, they
do not dare to get involved in anything infratructure if they can not prove
beyond a doubt that there will be a financial gain within the next 2..3
quarters - however small the actual investment would be! Can you blame them ?

So, given this market situation (*mumble* *mumble* i want my good old pre
1995 Internet back ;-), IP multicast will grow out of those closed loop
business cases, and when we're lucky, actual eyeball ISPs will not
only use those to provide another preprovisioned set of 100 TV channels, but
also allow receipt of arbitrary Internet sourced Ip multicast traffic,
so that the open ended promise can start to work!

For this to happen, quite frankly i would not bet on the incumbants, as much
as i would like them to be there, because i trust them to have the most
solid expertise, but unfortunately they also have the lowest market driver.
And incumbants can mean as much "country with well established infratstructure"
(dismal but sufficient cable or dsl) as it can mean actual companies.

  Toerless

5

the IETF's efforts have been extremely fruitful.

That is good to hear.

Dave

6

David Meyer <dmm@sprint.net> writes:

Here's my $0.02 on the whole multicast thing. We've been at this
for a number of years now, and robust, ubiquitous multicast
on the internet is really nowhere in sight.

1. The problems that multicast solves are also solved by the favorite
solution of business: buy your way out of the problem. Bigger
fatter pipes. More bandwidth. Beefier routers. The problems have
been addressed (papered over) by an alternate -easily implementable-
but not superior algorithm.

Kind of sounds like
QoS, and maybe there's a lesson there (20 years of research and
IETF activity, yielding, well, what?).

2. The problems that Qos solves are also solved by the favorite
solution of business: buy your way out of the problem.

Given the amount of time and resource we've spent on multicast,
the question one might ask is "why hasn't multicast succeeded"?

goto 1. recurse.

I do think, however, that we've all gotten it quite wrong since the
beginning. Multicast is not a subset of IP. It is IP. With a
different view of the protocol, unicast IP is a multicast group of 2.
Broadcast is a multicast group of all... perhaps if the infrastructure
reflected that from the get-go, we wouldn't be in this situation.

Peace,

Petr

7

How about as a service provider... How could you possibly bill someone for
a packet if you have no idea how much of your network resources it will
consume?

Most people bill at the customers' port, as a receiver of multicast there
are no issues, but as a sender I havn't seen anyone come up with a
satisfactory way to charge for it.

8

>
> FUD. What problem with billing models ? If you are an ISP, you are selling
> bandwidth. If another receiver joins the content , you get another piece of
> egress bandwidth filled up which hopefully is being paid for. If you need
> to cross-charge this back to the ingress-point, so do it. You just
> technically can't simply have accounting points on your exchange points
> anymore if you need to do so, you also need them on the delivery side of
> your network. More complex things than this have been done in the past.
> And of course, that could even be improved if demand for technology
> improvements was there (like eyeball count transmission via PIM).

How about as a service provider... How could you possibly bill someone for
a packet if you have no idea how much of your network resources it will
consume?

If I source a 1Mb/s stream my upstream can be assured that it will use no
greater than 1Mb/s on each of their multicast transit links...

that may require a different billing structure than unicast but it's easy
to measure (netflow) or bill for...

their internal network make look strange though.. if they have a full mesh
(mess maybe) mpls network provisioned on top of their access circuits they
may carry the same traffic more than once of the same link... such are the
joys of tunnels.

9

In a message written on Tue, Jul 09, 2002 at 09:33:51PM -0400, John Fraizer wrote:

One of your clients is a mcast sender. You bill him/her for the traffic
on their port.

Five of your clients are mcast receivers. You bill them for the traffic
on their respective ports.

Worst(best?) case scenerio: The sender and the 5 receivers are all on
your network. You get to bill all six of them.

Works fine.

If the sender is outside of your network and you have to deliver the mcast
to 5 different points on your network to your 5 mcast receiver clients,
you only see the mcast enter your network ONE TIME. You STILL get to bill
your 5 mcast receiver clients for the traffic on their ports and you only
have to INGRESS one copy of it to distribute to your 5 clients.

Works fine.

So, what is the problem?

You have a multicast sender on your network, and the 5 clients are
on 5 different peer networks. You just carried 5 times the traffic
on your network, and billed your client once.

10

Do source based accounting on egress into your peering points and cross
charge sent multicast traffic back to the traffic-source. Or better,
change the peering policy costs for multicast traffic to better adopt
to it's characteristics. But agreed. This is the case where the source
get's the most added value out of your service without the currently
set up accounting schemes to work well. It would certainly be possible
to nicely keep the accounting problem down to the ingress router by
aggregating these egress link counts via PIM.

Cheers
  Toerless

11

...and perhaps also because there is "enough" bandwidth currently, and that adding bandwidth is easier/cheaper/more stable/more well known than enabling multicast?

Just a guess.

- kurtis -