Subject: RE: mbone packet losses - production vs. research

From: Arlie Davis <[email-masked]>
Date: Wed, 12 Feb 1997 16:22:09 -0500

Yes, I'm chiefly referring to pruning not working well, at all.  (First
of all, don't think I'm ungrateful.  Multicast routing technology has
come a long way, so have the applications.)

First of all, the topological positions of the receivers and sender(s)
of a multicast session should be irrelevant.  Scoping with TTLs is a
bad, bad thing, for lots of reasons.  First, what if I really, really do
want to join a session that is going on in Tokyo, along with 30 other
people in Tokyo?  You don't want the session "bleeding" over the rest of
the multicast infrastructure.

Well, I won't waste anyone's time with criticisms of the infrastructure
of which everyone is aware.  I'll answer your questions.

1.  If multicast routing worked the "way it is supposed to work", then
there would (in all likelihood) be adequate bandwidth available on the
Internet and MBONE (same thing, eventually) for a wide, wide variety of
sessions.  Why?  Because for any given session, there are usually only a
small or moderate number of listeners.  This resembles the unicast
replication server, except that it is more efficient as you approach the
source of the stream.  If mrouting worked, I could multicast my
workstation's CD audio all day at a TTL of 127 and no one would even
notice unless they joined the session.

By "way it is supposed to work", I mean more than just having
prune-and-flood routers everywhere.  I mean something akin to PIM sparse
mode, such that flooding is never necessary.

2. Yeah, in the interim, inadequate solutions are necessary and you
can't quite beat on the infrastructure the way you would like to do.
So, yes, of course, I advocate treating the MBONE we have built with
kindness.

Why not pay for the streams you receive?  Or, pay for the cost of the
stream as delivered to you.  The cost to an ISP for delivering a stream
(of bandwidth B) to a given number of clients (N) is something like B /
N.  So, for the case of very few receivers (customers), the case
resembles unicast.  Bill something like unicast.  For the case of many
receivers, it's cheaper for the ISP, so bill cheaper.

-- arlie

>-----Original Message-----
>From:	James E. [Jed] Donnelley [SMTP:[email-masked]]
>Sent:	Wednesday, February 12, 1997 4:06 PM
>To:	Arlie Davis
>Subject:	RE: mbone packet losses - production vs. research
>
>>None of this would be a problem if multicast routing worked the way it
>>is supposed to.
>
>Are you referring to pruning?
>
>Beyond that, I question two things:
>
>1.  Even if multicast routing worked "as it is supposed to"
>I don't believe there would be adequate bandwidth available on
>the Internet to carry all radio and television broadcasts
>(or even telephone communication).  If you can't carry them all,
>how do you decide what gets carried?  I think that is the fundamental
>problem that we have with IP multicast as it stands.  The price of
>connecting and broadcasting is not enough of a deterant to slow any
>of them down.  At this point I think it is only momentium and
>lack of knowledge that is stopping them.
>
>2.  With multicasting not working "as it is supposed to"
>what do we do?  If not the Van Jacobson "be cool" approach,
>what?  In my opinion we desparately need some sort of mechanism
>for allocating available multicast bandwidth.  I personally think
>it should be tied to payment for service.  That way the sources
>that can benefit most by using the service can pay for it and
>contribute to building up the infrastructure.
>
>If something like that is put into place (though what it would
>be and how it would work I have no idea) then it would create
>a tension between the research community that continues to work
>on equally desparately need mechanisms (e.g. the very reservation
>mechanisms that are needed) and the production use of the network.
>
>Things are currently in a very difficult transition state as
>I see it.
>
>
>Jed Donnelley    [email-masked]   Phone: (510) 422-4309
>http://www.webstart.com/jed/    FAX: (510) 423-1355
>
>

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 13 Feb 1997 02:34:29 +0100 (MET)

> the multicast infrastructure.

There are a lot mote obstacles to internet-wide multicast deployment than
sparse-mode pruning alone. You'd first have to get good symmetric
routing into most places to make sparse-mode routing work (at least
for PIM). With the abundance of peering providers and ad-hoc BGP
connections, i guess that you won't have much success. Second you do
have to change router architectures to make them sustain multicast traffic
in the same way as they sustain unicast traffic. This is not
very likely either unless demand is there to pay for this. Until there's
enough of that demand, nobody will dare to spare a high percentage of his
routers capacity to multicast because it eats up this capacity faster than
it fills up the links thus wasting expensive link ressources. Trying to figure
out where in a distributedly administrated international backbone sparse-mode
traffic is lost due to rpf failure isn't my choice of weekend sports either.
Taking this together i guess that many service providers are not that unhappy
with heavily rate-limited dense-mode tunnel based multicasting infrastructure.
(And i havn't yet started talking about relay point placement).

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 12 Feb 1997 18:19:45 -0800

>> for PIM). With the abundance of peering providers and ad-hoc BGP

    Toerless, this is not true. We have sites running sparse-mode PIM over
    a partially deployed native multicast topology. The only problem is that
    they have to use slow-converging DVMRP unicast routing to make it work.
    But it does work.

>> it fills up the links thus wasting expensive link ressources. Trying to figure

    But they are using up spare capacity right now unicast forwarding the
    same data over the same links.

    People need to be a little more forward thinking and look at the long-term
    benefits of multicast. Right now it's unicast maintenance in your face
    because of the Internet growth. But if people can figure out how to
    balance maintenance and development (I contend with this everyday) we can
    get to full multicast deployment.

    But no fear, ISPs are taking major steps in getting there. Things *are*
    proceeding.

Dino

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 13 Feb 1997 03:41:00 +0100 (MET)

>     they have to use slow-converging DVMRP unicast routing to make it work.

Well, as for me, it's not natively deployed unless there's no tunnel left.
True. you have to go through the tunnel phase in between. That's where we
are now. So, if you want to get rid of the tunnels, and DVMRP in their
way, you have to get reliable symmetric routing, or rpf-failures will
hit you. That's the idea of PIM, isn't it ? So far people can benefit from
sparse-mode as a mean to reduce redundant traffic, but not of PIM in
itself to make life easier, because there are no tunnels to configure or
yet another routing protocol to watch over, like dvmrp.

>     same data over the same links.

I guess everybody of us has to see how much spare resource we can squeeze
out of our backbone routers unless the router manufacturers publish
some better multicast performance numbers (or let them publish by some guy in 
harvard ;-). I remember to have asked without much response exactly such
a question regarding these throughput numbers (tunnel vs. non tunnel)
to one of my favourite routing equipment providers (*hint*) to help me
in planning configured multicast bandwidth...

>     But no fear, ISPs are taking major steps in getting there. Things *are*

It's a chicken and egg problem. Nobody's interested in multicast unless
there's contents. No contents provider will start out the big way
unless there's useful bandwidth. Nobody in my damned region is
even thinking remotely about multicasting when buying $millions of
switching equipment for 100 Mbps ethernet *sigh*, *mumble*, *sniff*.
(which reminds me: anybody seen catalyst3x00 cmgp software ?)